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ABSTRACT 


The Monterey Security Architecture (MYSEA) provides a distributed multilevel 
secure networking environment where authenticated users can securely access data and 
services at different security classification levels. The MYSEA framework utilizes both 
commercial-off-the-shelf (COTS) products and specialized secure high assurance 
components that enforce multilevel security (MLS) policy. Some collaboration among 
MYSEA users is enabled through the use of the Web-based Distributed Authoring and 
Versioning (WebDAV) mechanism. 

This thesis extends the existing collaboration capability in MYSEA to include 
hypertext content-based collaborative authoring and information sharing through the use 
of the increasingly popular wiki technology. This is accomplished by porting a publicly 
available wiki engine to run on a proprietary operating system hosting the MYSEA 
server. Through a systematic selection process, TWiki was chosen as the wiki engine for 
MYSEA. A three-stage porting methodology was used to aid in troubleshooting porting 
errors. Functional and security tests were performed to ensure that the wiki engine 
operates properly while being constrained by the underlying Mandatory Access Control 
(MAC) and Discretionary Access Control (DAC) enforcement mechanisms. This 
research is synergistic with the cross-domain information sharing emphasis fostered 


under various R&D programs in the DoD and intelligence communities. 


THIS PAGE INTENTIONALLY LEFT BLANK 


vi 


I. 


Il. 


IV. 


TABLE OF CONTENTS 


TNT RO DUCTION cssiscssessstisecicbusevatnassoceossasanctaneinhes besavcheneasiavasanbaaaepumiencueseamsencnnann 1 
A. ILO TTY ATION < svscscssanssuicenceesesiascnsseunetaaescotutevecssiees aun ceansensueessunnstestesovesspunivens 1 
B. PURPOSE wcosissiscvcinssssensquaseuvvaisannvongogsnchapnnasesaucntcesecoustetnagausoagsaenssusessvaravennsaciens 1 
C. ORGANIZATION OF PAPER ............ccscsscesscscscscscescsescecsssscnccsescncssscesesssesoees 1 
BACK GROUND sicsisessersesessgassuudecnsanuensesvavancysacsensebesuberishocaagestneseensidssatsgenvneusieteyonseiues 3 
A. WV TI sass sessainavessntsvicSunessvesutecncesaainsneasncuecadsousensomscancovancoannsanaah fecenspunenantatennses 3 
B. IVEY SEA. cs cutesnsessnitectinseseuesiys ovsteecesubednennslesasonbeuedeuhoistecnsgebe taynouuscuscescedspsaneteceeniatesy 4 
C. MESAGO SERVER sivscsssneguasichuanenepnasecssaiveyesonceaaxeisguesn verncnncseonaptnceyeasanesssonnsudes 6 
1. Detlction Dir OCtory sosessscesscssncssocssscsseessuceusvesadesbonpncsvedassccssespudsvennsecesse 6 
2. DAC OFGANIZATION sicisctscSucstistinesetecedosctstavsnatestasatunedenscseceksteteoseacseelests 7 
D. SULIVEIVEA TRV sacs iccasicessiaus ncaa ccecedevees neo unestecaucedaseaevuenwas ves stnenes sucauvede svounseaneunnoneciuss 7 
WIKT ENGINE SELECTION wccsisccnds wivccensctscentsnsonacuscestasedyon sexs cdusdatectavetadeusevecssensacces 9 
A. AV AILGABLE WIKI ENGINES wiiissccssessssssensosscenscstsoneccasseenossendevassnesoosesnsdenses 9 
B SELECTION METHODOLOGY ............cccccsssssssscscesscescsrscsecsecssessenssecsonsssnss 9 
C. SELECTION ‘CRITERIA ... .sissecsosnesnsenscosscessossoonsesnssnscestsvecestvesvecnsenssoaesneseds 10 
D SELECTION. PROCESS wssessssiscsscttvaccanecscoudsvatacasnncgsiicnnsonssauvceaneoavereccaveevones 10 
1. Concurrent EGit FO QGUIrG 6s siccissassscsasesdsndas ccedesserscsdondsceacacctdsneanacsdsaes 11 
2. Executable COdG S126 oisécisecsssessssscnscsdcestsssadbetuavscerseseevacsvendsncenacedentedees 13 
3: Process Memory Footprint..............cccccccsscccsssccsssscscsssesssssescsssssesseees 14 
4. DIP ECLOFY SUPUCE UTES sisssccsses sess sides uesseecsadealasnesteaventtecicctaepsanspaeeiacssetats 14 
3: Fun tionalities: Designs). ccscsssssvsseoscssecssssosessbusussseessssenvedertenscenssddeacceate 18 
E. SELECTION OU PC OME si sursisccssecscevssnscedscsassgencen s¢ecsneusssagenescocussenstensoactedtose 18 
F. SU MEIVIAR Y. vcsssccsencisensscesecpovs chips nw dtentteBedepuveseeseubeuend aihestenecnmbedensnesenceenees stbenes 19 
PROJECT, DESCRIPTION scisscisacesotsivasensoacstcessnestesssudessbnatestesonaccochbocessesyadeveniantoss 21 
A. CONCEPT OF OPERATION sicccsssssessesssesneedssstesnsessscessdoioensontesonedusieosoonssoees 21 
B. METHODOLOGY sisscsvsssectssusssctassdernsees tesa tavgushiucdeassteondeanieavevnaseuspeshsandanstiens 22 
1. DAMN sccicessas scsccheeeseaatiesia ccsussscatnastauceshecpsavsebccecstavcdusssauseacetaesscnsasoesadsese 23 
pe Single Level Mode on the XTS.............sccssscccssccccsscsccsscccsssescsseseees 23 
3. Multilevel Mode on the XTS .............sccssscccsssccscssescssesscssescessesessenes 24 
C. SU IMENGARY 15 ss6ssscsvsnvusdsatasicavsceasacasoenpussvenatacenvarniesseutiacsteshonsivonneacoosstpnessannvacens 24 
WIKI DESIGN AND ARCHITECTURE 2... ccccccccccccsccccscesceesseecsscssseeesseeees 25 
A. STANDARD TWIKI ARCHITECTURE 2..........ccccscsssscssesscecscscsscseseeseeeees 25 
B MLS WIKT ARCHITECTURE 10...0......csccssccsscsscscsccsssssescssesscessscsssssscssocsenees 27 
C. WIHIKE ISSUES IN MY SEA «oi asssvasscicsascvisevccesstasequansttonspuvevancoosssanssusdbigeessuvonses 30 
D SOLUTIONS TO THE TWIKI DAC PROBLEM .............ccsccssssssssceeseeeees 31 
1. Restricting Interactive Shell Sessions.................sscscssssssssssscssssceeeees 31 
De ATS Access Control Last sccsscsiscivcsssscncsctoccasccoanesovansasavcderessscanssvonceeens 32 
3. Proposed SOLUTION .............sccccscccsssccccscccssscccssscssesssccssssseesssssesssssesseees 33 
E. DIVER LE NEEIN FAT LOIN -ssassonasessiasvaissonnessteesecssonapvedeouisesdeasoenesaeanevaenonnnesspeboenaes 34 
F. SS UIVEIVIA RR Y 5. oi ccksntsoscenectscaeandesscbuccoksreesdbavendecestavackeswstenasecavuconsesascuncevocsesmaaeens 35 


Viv “TESTING AND RESULES sisssssccusccacenstsorinssinsisussveoes scnvecscesstenceevasdeovincebasiesssbevenceeses a7 


A. FUNCTIONAL: TEST PLAN  cascsecccssocsscnacaacesasonsnsccessduscenasoasceactensgnaseecsnaceess 38 

B. MSEN UX DES PUN Gccesicesisscussevesnacteivspiesicensiede viveensiiedoeueds es onutvncestaacecsnicesesteenets 39 

1. EWG DA C Vest PLA iisaj ssssaysnncscizonsysiassntessquasssasnrannsdeqannseasagnontivisanteeey 39 

2s GSE PR GSS ised scessedczcciazcecactvexestustacessteateshousastecsstpeuecbupbecnsetsituesannaudecs 45 

C SINGLE LEVEL XTS TESTING ..000........cssccsccssccccscscscsscscscssecssesssessessnesees 46 

1. TWiki DAC Test Plan — Single Level Configuration...................... 46 

2s MAC Test Plan — Single Level Configuration. ................ssscssssssees 48 

3. Test Results — Single Level Configuration. ..............scccssccssssessseeeeee 48 

D. MULTILEVEL: XTS TESTING cisstsssiciscssccassissensosasenstencsnncvosontsonssasensosisvencs 50 

1. TWiki DAC Test Plan — MLS Configuration. ...............scssscssseeeee 50 

2. MAC Test Plan — MLS Configuration ...............sccssscsssccccssescseeeees 52 

3. Test Results — MLS Configuration ...............scscssccssscsccsscsccssssceesenes 53 

E. INTEGRATION TEST PLAN .............ccsccsscsssccccscscsccssscscssscsscscsescessssesceseees 54 

1. OST ROS ULES i. actctsaccesustecastecistucnscbenncesteavesnessaasepcbdensncdevnadestisencundessncexets 55 

F. SUIVEIVEA RY cscs cs veuscuacavavacesiissuedesstavusevoussasevenssnesesaaueonts sanuosoukbacssvespiseveaionsocs 55 

VII. CONCLUSION AND FUTURE WORK ....00........ccssccseccsceccccscsccsesescscncesesssesensssesees 57 
A. COIN CIUSTION sense sucscansaascs dseseeaagnsvecss cavseensebioessescehussqavesbses dsasueusessiesenancseisteass 57 

B. RELATED WORKS siscsocssssescscctonsesassokssunecisenccnsonnstesioiseeacduucess ovbeseedeuseccassienese 57 

C. PUURE -W ORK. iajsstcssgsesecsceeonsnivancnqadsnysaieeeavanwoaansonetoounn tab anadeibenaseneusgonaciens 58 

1. Wiki Password Synchronization...............ssccccsscccssscssssscsssseseessesseeees 58 

2. Cross Domain Content Merge ...........ccsscccssscssssccscssesscescescessescessees 58 

3. Removal of SMTP and IMAP Services on Wiki Server..............0.. 58 

APPENDIX A: INSTALLATION PROCEDURES .......... cc cesscscssesscsesscesscessesscesenes 59 
A. INSTALLATION AND TEST TOPOLOGY .u...........ccsscssscssccescceseeeceeseesees 59 

B. LINUX. TNS PA LLA TION sisssssscsveasssussotsiaesvevsantessabuscvonssuvosseasvacsesipeseonsensecess 60 

C. SINGLE LEVEL XTS INSTALLATION ...00........sscsscssscsssscscssescscncssesssesones 64 

D. MULTI LEVEL XTS INSTALLATION ...000......eesecccccececcccscscscessscsenereoees 69 
APPENDIX B: TEST PROCEDURES wicsssssecsssnsessessavenssasenssenspengancssatansocanveanasspusenses 79 
A. DESCRIPTION yincisesccastonsencsesyaaeousesutontoasesaesuusvousedsnsuccossoncsecspnsgeceossnontesvavanes 79 

B. PEST DE TATIES sac yesssgsegasastbocaseseatassavtedgesttedewesstenceke snes vevesunyatessastacyesetasegesastees 79 

1; RESUS CUUDS csajstevacssasavussbsctiesdsasdeoudetoveds sopaveucuabannscossivasbesneneiecsnaviesectues 79 

2s GStPROCEMUIES oisiccsccsbaeSankcacecscasesdcesbensccccseatcdas sods cetcsesscastenccuastensieacchs 83 

APPENDIX C: MLS: TWIKI USER GUIDE siscsssesseisccasssatectesereessensonasvestapnenesesoesees 117 
A. MLS TWIKI WEB ORGANIZATION .........ccsccsscssscsscscsscssssssesscesssssesseees 117 

B. GETTING STARTED 6 ssnssnsenscsnctucsoesvaseoasvabiedntendyanntoncestverecensenesidesnebedendaione 118 

OF BASIC OPE RATIONS wsisscsssspssessanvcsnnniguiscvieesanguteusbessssavevassasvsecstitenseereiebesws 118 

EIST OF REFERENCES ssisscsccosiedsesnsscesectevecnssvodeusdeersedusepsceasonpene coeusonseenegedethocgabseucctivensosbes 121 
INITIAL DISTRIBUTION LISD iscsiececcscevssnvcsvecoasseasstaycrsocossucestesgasensensvensonscewsconsevecsnsseses 123 


Vill 


Figure 1. 
Figure 2. 
Figure 3. 
Figure 4. 
Figure 5. 
Figure 6. 
Figure 7. 
Figure 8. 
Figure 9. 
Figure 10. 
Figure 11. 
Figure 12. 


LIST OF FIGURES 


MYSEA Testbed Topology [From 10]. .............ccecccesscesesesceeteccenseesenseecetseneeneees 6 
Par Wikt Directory Stu Cun ee soc occured sess asses acau aes ane Haste eee cea 15 
PWAki Diretory SMuCtr es ju. ive casssteleansdsvelestuendiaeagenahes dea vguesazsaghessiansusnenedoenatees 16 
Organization of Wiki Pages by Topic... eee eeeeeseeeescecsseceeeeeeeeesseecsaeenseensees 16 
Organization of Wiki Pages by Classification. .......... ccc ceeeeeceeeseecseceteeeeeeeenees 17 
Waki Darector ye S (UCU Cocos case. sheds ajecsy duaseavsucestds te eattansusytads aiesaanaaciananSotier, 26 
TWiki Sub-Web Directory Structure. ........ cc ceeceeeseceeeeceeeeeceeeeeceeeeeeesteeeenaeees 2 
CES ANI ZATION Dy: POPC. BGs sige vas cele sees el geo acaatauodnses seduce ae vanns@osusesneeseeers 28 
Orsanization Dy Classi fi Calo mens joan ucssnns oe Gnade adie cos sSev eee wdganees eS ave eats 29 
Directory SIUCHIIG . ieissc ceive ceaas Wy atessasedesuusdesaaa sea sass cessed ea nbeban tats donedaonaden te lessens 34 
Network Topology of Test Setup... ceecccsescecsencecesececeeeeeceeececseececseeeeeseeeees 38 
Test Setp Network Fopologys ss.1; ce sessasgast aera aiedaneuen eats 60 


1X 


THIS PAGE INTENTIONALLY LEFT BLANK 


Table 1. 
Table 2. 
Table 3. 
Table 4. 
Table 5. 
Table 6. 
Table 7. 
Table 8. 
Table 9. 


Table 10. 
Table 11. 
Table 12. 
Table 13. 
Table 14. 
Table 15. 
Table 16. 
Table 17. 
Table 18. 
Table 19. 
Table 20. 
Table 21. 
Table 22. 
Table 23. 
Table 24. 
Table 25. 


LIST OF TABLES 


Selection Decisions and Elimination Process. ...........::ccesseceeeseeeeeseeeeeteeeeneeeenes 12 
Summary OF Selection: PrOCESS.:.; sues wcccgccesdedeseuesnaaauesbavedssdeeesneenncadscsdnacenceancke 19 
List.of Functional Test. cisssiciistesavsadassazedaseecadensscvadtassecnctesvaceeds secvnwadperadeasecceers 39 
Permitted Values and Processing Rules of TWiki DAC Settings... 40 
Order of TWiki DAC Rule Evaluation (After [17]). .......cc cc cccccsesssseceeeeeees 41 
Possible Combination of TWiki DAC Setting. ....... eee eeececeseceeseeeeenteeeeneeees 43 
Test Scenarios and Test Cases Performe2a. .......... eee eeececesececeeeceetteeeeseeeenaeeees 44 
Meanie VRC GS. oes tied gan Gnct cas Sacto cadtaSip adlute Mieatca dan oenc ak onsen aeatecngs 45 
Linux Server Functional Test Results......... cece ceesceeesececeeeeceeeeecseeeeceeeeeeneeeees 45 
Einux Servers DAC Test Resultss aiais3.iec keds faces dedahayseastuaseguanted sotedoonsdedsbeanuweteceani 46 
singlé Level XTS TWikt DAG Test2: ganciyte Benue cheb i actenlae eevee: 47 
mingle Wevel NIAC Test, scphacsccciess ar ceatasovmashdevecenicossaeeosiauaceds saveechtnsecomastiam ae saance 48 
Single Level XTS Functional Test Results... eee eeseeesecsseceseeeeeeesaeenseeeeees 49 
Single Level XTS TWiki DAC Test Results. ........ cee eecceceeceecseeceesneeeenneeeenes 49 
Single Ihevel ox TS MAC RESUS 53. c sin: ease cede saver adasevcndvasaeeansqussneve esse 50 
Multilevel OCS TWiki DAC Test cise. cozsasteecian dees seasuucniassheecauesteaageenountestanaeae 51 
Multilevel XTS MAC Vests .ccssssecanaveigeisessusine st loedjacasgenddtunsdccats sedsaasedessceeastacades De 
Multilevel XTS Functional Test Results... cee eeeccecesececeeececeeeeeesseeeeeeeeeees 53 
Multilevel XTS TWiki DAC Test Results........ cece eeeeeceecceceeececeseeeeeeeeeeeeaeeees 53 
Multilevel XTS MAC Test Results. ..cciccissccacsaspacaateloessetessaceedtscevedeacesracdetadceers 54 
LAStS “OF IME SLALON TES tie. ssa ienrsenu st Orsed. oolaaivecauls sua Seageatuacsh dass ahaascutoe any: 54 
Multilevel XTS Integration Test Results. 0.0... eee eeseesseceseceeeeeeeeenaeenseeees 55 
Functional Test Permission Settings ............eecccesscecsececesececeeececesececeeeecneeeees 80 
DAC Test Perinsston: Senn es 34: cosscasesctagactesndesadessaadseedutaes ant sespousedetastcanpezeeanans 81 
MAC Test and Integration Test Permission SettingS........... cee ceeeeseesseceeeeeees 82 


Xl 


THIS PAGE INTENTIONALLY LEFT BLANK 


xii 


ACKNOWLEDGMENTS 


I would like to express my sincere thanks to many individual who have assisted 


me throughout the course of this thesis study. 


I would like to thank Prof. Cynthia Irvine and Thuy Nguyen for the time and 
effort in helping me to formulate the scope of the thesis, and guiding me throughout the 
length of my thesis research. Thank you for your patience and constructive comments in 


making the writing of this thesis paper a success. 


I would like to thank Jean Khosalim and David Shifflett for their technical 
expertise and assistance in helping to troubleshoot the problems encountered during the 
implementation process. I am grateful to Jean for his patience and time in going through 


the installation instructions and test procedures to make them error free. 


I would like to thank my sponsor, the Singapore Defense Science & Technology 
Agency, in giving me the opportunity to pursue this postgraduate study at the Naval 


Postgraduate School in Monterey. 


Finally, I would like to share the success of the completion of this thesis research 


with my wife, who is constantly encouraging and supporting me. 


Xlil 


THIS PAGE INTENTIONALLY LEFT BLANK 


XIV 


I. INTRODUCTION 


A. MOTIVATION 


The use of wiki systems in corporate environments has become increasingly 
common. The ease of interaction and general operation for typical users makes wiki 
system an excellent tool for mass collaborative authoring. However, in a secure 
environment where users are subjected to strict access control policies for data with 
different security classifications, i.e., a multilevel security (MLS) environment, extra care 
should be taken to ensure that the wiki solutions are usable while still conforming to 
security policy. The motivation of this thesis is to demonstrate the feasibility of 
implementing a wiki solution in one such environment, i.e., the Monterey Security 


Architecture (MYSEA) [1]. 


B. PURPOSE 


The purpose of this study is to determine whether it is possible to develop an 
architecture for incorporating wiki technology in a MLS environment and if so, to 
implement a wiki server in the MYSEA MLS Testbed. This study will enable 
collaborative authoring and sharing of information in a multilevel secure environment. 
Such a capability is beneficial in a coalition environment, whereby information with 


different sensitivities is shared among different entities 


C. ORGANIZATION OF PAPER 


This work is organized as follows: 
e Chapter I provides the motivation and purpose of this study. 


e Chapter II gives background information regarding wiki technology and the MYSEA 
project. 


e Chapter III describes the selection process for candidate wiki engines. 
1 


Chapter IV provides the project description, which includes the concept of operation 
and the methodology adopted for the study. 


Chapter V describes the wiki design and architectures, the problems encountered and 
the proposed solution. 


Chapter VI provides the testing procedure for the wiki implementation, and the 
results of the testing. 


Chapter VII concludes with a project summary, a discussion of related work, and 
suggestions for future work. 


Il. BACKGROUND 


This chapter provides background information on various topics relevant to the 
implementation of a wiki in the MYSEA environment. The first part of the chapter gives 


an overview of wiki technology, and the second part covers the MYSEA project. 


A. WIKI 


Computer and communication technology have enabled the use of computer- 
supported cooperative work [2]. Such computer-supported collaboration technology 
provides a means for mass collaboration in which a group of people creates content 
collectively rather than individually, and one such mass collaboration tool is the wiki [3]. 
A wiki is a website that allows a visitor to view, add, edit and delete the content of the 
website. Such ease of interaction and operation makes a wiki an effective mass 
collaborative authoring tool. The wiki was first developed by Ward Cunningham in 
1994, who named his work “wiki”, a Hawaiian word for fast, which is meant to represent 


the working principle of such a mass collaborative authoring tool [4]. 


A wiki engine is usually implemented as server-side scripting technology [5], 
though there are also client-side technologies, but they are less commonly used. The wiki 
engine manages a set of documents known as wiki pages. A wiki page is written in plain 
text and stored either in a regular file system or in a database. When a browser requests a 


page, the wiki scripts translate the wiki page into HTML and returns it to the browser. 


Besides the content, the returned HTML page also contains a header with links to 
scripts with specific functionalities. The most important of these links for a wiki is the 
“edit” link, which differentiates the wiki page from normal read-only webpages. When 
the “edit” link is clicked, the script returns the same wiki page, but in this case it is 
enclosed in a text-area form with a “save” link below. The reader can now edit the text 
and submit the new version via the “save” link, which immediately replaces the old 


version on the website. When the “save” link is clicked, the data in the text-area form is 


3 


sent to the wiki script, which stores the new text as a new version of the wiki page. The 
wiki engine usually controls the versioning of the wiki pages using a revision control 
system, and maintains a log of recent changes called a “history”, thus allowing users to 


revert to previous versions of the wiki page. 


The source format of the wiki page is augmented with a simplified non- 
standardized markup language to indicate various structural and visual conventions. 
Each wiki engine implements its own simplified markup language and there is little 
standardization among the wiki engines. HTML is not used because the tags make the 
actual text content hard to read. Therefore, plain text editing with a few simple 
conventions for structure and style is preferred in most wiki engine implementations. 
Hence, users only need to remember those few simple conventions and do not need to 
learn a cryptic code language like HTML. Another important feature of wiki technology 
is the wiki page link syntax, which is the syntax for creating hypertext links to other wiki 
pages [5]. Most wiki engines follow the syntax of enclosing a word or phrase in a 
[[double bracket]] to indicate a link to a wiki page with that name. Creating wiki page 
links is also the method for creating new pages. If the word or phrase enclosed in 
brackets is not the title of an existing page, a link is created that leads to the edit form for 


a new page having that title. 


The wiki design outlined above permits easy creation and editing of page 
contents. It is the use of simplicity as an overarching design principle that makes wikis a 


widely used tool for mass collaborative authoring. 


B. MYSEA 


The Monterey Security Architecture (MYSEA) project aims at developing a 
secure architecture to enable the aggregation of data and services at different security 
classification levels into a distributed multilevel secure network. It is accomplished 
through the use of commercial off the shelf (COTS) products together with secure high 
assurance components that enforce multilevel security (MLS) policy. The high assurance 


products ensure that security is enforced across various sensitivity levels without having 
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physically separated hardware for networks at each sensitivity level. MYSEA aims to 
achieve a higher adoption rate than other MLS systems for organizations which already 
own a substantial number of COTS resources and do not wish to invest in new systems, 


by using a mix of COTS and special purpose components [1][6][7]. 


The multilevel security policy that the special purpose high assurance products 
enforce is formalized based on Bell-LaPadula mathematical model [8], where a subject is 
allowed to read an object only if the security level of the subject dominates that of the 
object, and write an object only if the security of the object dominates that of the subject. 
The products also enforce the integrity policy reflected in the Biba mathematical model 
[9], where a subject is allowed to read an object only if the integrity level of the object 
dominates that of the subject, and to write to an object only if the integrity level of the 


subject dominates that of the object. 


Figure 1 shows the MYSEA network architecture. Communications between the 
clients on the MLS LAN and the services within the MLS enclave as well as the services 
on other connected single-level networks are handled via the XTS-400 high assurance 
MLS server. Once the session level is negotiated, a client can communicate as permitted 
by the enforced confidentiality and integrity policies. A Trusted Path Extension (TPE) 
device between the client and the XTS-400 server provides a mechanism for user 
identification, authentication and authorization, and supports negotiation and 


establishment of the session level. 


The MYSEA MLS server supports HTTP, IMAP and SMTP protocols. The 
support of HTTP allows a wide range of applications such as the Tarantella web 
enablement software and WebDAV to be used. In particular, WebDAV provides the user 
with the ability to remotely access and modify files in the MLS context. A wiki, on the 
other hand, provides a means for rapid and distributed authoring of shared content. The 
goal of this thesis is to provide such mass collaborative authoring functionality through 


the implementation of wiki technology on the high assurance MYSEA server. 


- App Server 
- Client 


- C2PC Gateway 
- C2PC REPEAT Server 








E - Encryptor . ae 
TP - Tarantella Portal Server Ue gree aut nomen Internet 
TCM - Trusted Channel Module c= Encrypted . 
Figure 1. MYSEA Testbed Topology [From 10]. 


C. XTS-400 SERVER 


BAE System’s XTS-400 server is based on Intel x86 hardware and it runs the 
STOP operating system. STOP provides a Linux-like user and programming interface 
which allows many existing Linux applications to be ported to the XTS platform without 
significant modification. The XTS-400 server enforces both discretionary access control 
(DAC) and mandatory access control (MAC) security policies. Many features are 
available on the XTS-400 server, two are relevant to this study and are briefly described 


in the following sections. 


1. Deflection Directory 


In multilevel mode, STOP allows users to login to the XTS-400 at different 
session levels. They can read data with security labels at or below the established session 
level, but only write to data with security labels equal to the session level. If a directory 


is created at a particular level, the user will be able to take actions that would result in 
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changes to the directory only when logged in at the session level equal to that of the 
directory. Many typical applications use standard directory paths. To allow the use of 
the same apparent directory path at different session levels, STOP implements deflection 
directories. A deflection directory is a special directory that can be instantiated at 
different security levels simultaneously. When a user accesses a deflection directory, the 
OS automatically selects or creates an instance of the directory that corresponds to the 
user’s current session level. A typical use of deflection directory is “/tmp”. No data is 
shared between different instances of the deflection directories, and it is not possible to 
access instances of the directory at other levels. Although the use of deflection 
directories allows data to be written to what appears to be the same directory at different 
levels, the OS ensures that data within such directories is properly separated according to 


their security labels. 


2. DAC Organization 


In MYSEA, the Apache processes are instantiated with the userID of the 
authenticated user, i.e., the IDs of the Apache processes are the same as the ID of the 
logged in user. As such, any files created by the Apache process running on behalf of an 
user would be owned by that user. This is different from the standard Linux 
environment, where the Apache processes take on a dedicated userID, and any files 
created by those processes would be owned by that userID. This difference results in 


some challenges for this study, which will be elaborated in Chapter V. 


D. SUMMARY 


This chapter provided an overview of wiki technology, outlined background 
information on the MYSEA environment and discussed XTS-400’s features of deflection 
directory and DAC organization. The next chapter will elaborate in details the selection 
criteria and outcome of the selection process used to choose an appropriate wiki engine 


for the MYSEA environment. 
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Hl. WIKI ENGINE SELECTION 


There are many different wiki engine implementations available, each of them 
differing in many aspects. To help in identifying a suitable wiki engine for use in this 
study, a structured approach in the selection process is adopted. This chapter outlines the 
wiki selection methodology, the selection criteria for the wiki engine for the MYSEA 


testbed, and the outcome of the selection process. 


A. AVAILABLE WIKI ENGINES 


Many different software technologies and solutions have been adopted in the 
Open source community to implement various wiki engines. A search on wiki-related 
websites on the Internet returned about 140 different wiki engines[11], implemented 
using a wide range of programming languages such as C, Java, PHP, Perl, etc. Each of 
these wiki engines offers a differing breadth of functionalities. It is therefore crucial to 
adopt a sound methodology to aid in selection of a suitable wiki engine for use in the 


MYSEA testbed environment. 


B. SELECTION METHODOLOGY 


Due to the availability of many different wiki engines and the widespread 
adoption of wiki technology, many comprehensive comparisons of wiki engines have 
already been done and the information is available in the public domain. The approach 
taken here is therefore not to reinvent the wheel, i.e., to repeat those comparison, but to 
leverage existing information to help in the short listing process [12][13][14]. While 
reviewing the information, weights have been given to considerations of specific interest 


to the MYSEA testbed so as to make the selection relevant to the operating environment. 


C; SELECTION CRITERIA 


The primary consideration in selecting the wiki engine is that the wiki engine 
must be able to integrate into the MYSEA environment. The wiki engine must therefore 
be able to run on the RedHat 8.0 operating system, and be able to integrate with Apache 
HTTP Server Version 1.3.34. To keep the setup simple and to aid in troubleshooting, it is 
desirable that the selected wiki engines depend upon the standard file system instead of 


on special purpose databases for their data stores. 


The maintainability of the software is another important consideration. A well 
maintained wiki engine will ensure that the wiki engine is up-to-date, and that public 
domain support is available should there be any issue. The Top-10 wiki engine list was 
used as a proxy measurement for the maintainability of the wiki engine. The rationale 
was that a more popular engine would imply that more people are using it and hence 


more people are willing to enhance and support it. 


The supported functionality of the wiki engine is also an important consideration. 
The selected wiki engine should be able to support most of the essential features of a wiki 
engine. To aid in the comparative analysis, a popular wiki engine, MediaWiki, was used 
as the baseline to which the functionality of the wiki engine was compared. MediaWiki 
was chosen as the baseline because it is the underlying wiki engine for one of the most 


referenced wiki websites: Wikipedia. 


D. SELECTION PROCESS 


Upon application of the considerations outlined in the preceding paragraphs and 
using publicly available information [12][13], the list of wiki engines was narrowed from 
the initial list of more than 140 to a final list of two. Table 1 presents the detailed 
selection decisions and the elimination process. The two candidates were PmWiki and 


TWiki. PmWiki is a server-side wiki engine with an implementation based on the PHP 
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scripting language, and was started by Patrick R. Michaud [20]. TWiki is another server- 
side wiki engine started by Peter Thoeny, and is implemented using the Perl scripting 


language [21]. 


In order to select the final wiki, the following additional criteria were used: 
concurrent editing features, executable code size, process memory footprint, directory 
structure, and functionality design. The following paragraphs outline these criteria in 


greater detail. 
1: Concurrent Edit Feature 


As the main feature of a wiki is the ability to simultaneously edit the contents of 
a page by different users, it is therefore important that the wiki engine be able to handle 
this concurrent editing functionality. Specifically, the wiki engine must be able to handle 


the following scenario: 


Alice starts to edit a page. Before Alice saves her edits, Bob requests an 
edit of the same page, and receives the page’s text prior to Alice's edits. 
Bob finishes with his edits and enters "save". Alice finishes editing her 
page, enters "save", and since she is working from a version of the page 
obtained before Bob has made his changes, she may wipe out Bob's edits in 


the process. 
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Elimination Process — 
Fe 
Wiki Engines FileSystem ' Top 10 Wiki List Apache Functionality 3 ACL? OpenSource functionality 3 | Shortlisted 
fil kwiikwki | 2 [SSS SSS: 
}2 | Dokwwaks |) 
Pa | sspwit | |r 
| 4| Perspective | 1 |) 


|S | Flewwaci || 
[6 | usemoawas | | wm | | 
[7 | oumewni | 2 | W&@ | &@ | 2 SSS 5:5 
| | 
[9 | 





Information Source: 1: http://c2.com/cgi-bin/wiki? WikiEngines 
2: http://c2.com/cgi-bin/wiki?TopTenWikiEngines 
3: http://www. wikimatrix.org 


Table 1. Selection Decisions and Elimination Process. 
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PmWiki handles such a scenario by implementing a concurrent edit feature using 
the “diff3” UNIX command. Essentially, instead of saving Alice’s edit, PmWiki presents 
a message saying someone else has changed the text while she is editing it. Bob’s 
changes are merged into Alice’s text, with any conflicts highlighted by parentheses. 
Alice can then fix the text as appropriate and save the updated pages. However, PmWiki 
does not inform Bob that someone is editing the page when he first requested to edit that 
page. 

TWiki implements a similar concurrent edit feature using a Perl implementation 
of the ‘diff’ command to show the difference between the versions. In addition, TWiki 
prompts Bob in advance, and gives him a choice of canceling or proceeding with the edit. 
TWiki is also able to handle the case whereby both users concurrently save the edits. 
PmWiki, on the other hand, handles this situation poorly, as one version of the edit will 
overwrite the other without invoking the concurrent edit warning prompt. In this aspect, 


TWiki is preferred over PmWiki. 


2. Executable Code Size 


Both PmWiki and TWiki are implemented using scripting languages. A 
comparison on the total executable code sizes of the scripts was obtained to serve as an 


indicator of the underlying complexity of the code. 


PmWiki organizes its code into a main PHP script file called pmwiki.php, and 
supporting PHP scripts in the “script” directory. Users invoke PmWiki via the main PHP 
file, which then calls the other supporting scripts as necessary. The total size of the main 


file and 33 supporting scripts is 841 Kbytes. 


TWiki organizes its code into two directories: the “bin” directory for the main 
Perl scripts, and the “lib” directory for supporting Perl modules. User invokes TWiki via 
the “view” scripts in the “bin” directory, which then activates other supporting modules 
as necessary. The total size of the 230 script files in the “bin” and “lib” directories is 


2262Kbytes. 
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In terms of code size, TWiki is more than two times the size of PmWiki. This 
provides an indication of the relative complexity of the two wiki engines. In this aspect, 
PmWiki is preferred over TWiki. However, the simplicity of PmWiki does have a 


downside in terms of functional robustness, which will be discussed in a later section. 
3. Process Memory Footprint 


The preceding paragraphs illustrate the relative complexity of PmWiki and TWiki 
through comparison of the executable code sizes. To further explore the process footprint 
of the two wiki engines during execution, their memory usages were monitored and 


compared. 


The “top” command in Linux was used to list the amount of memory used by the 
two wiki engines. The “size” variable given by the “top” command gives the size of the 
process’s code plus its data and stack space. In PmWiki, since PHP is compiled into the 
Apache code, the “top” command was used to monitor only the “httpd” process. It was 
found that PmWiki consumed about 4Mbytes of memory during execution. In TWiki, 
the Perl script interpreter is not integrated with the web server. Hence, there is a need to 
monitor both processes. It was found that the “httpd” process used 1016 Kbytes and the 
TWiki “view” script used between 5 and 12 Mbytes of memory, depending on the pages 


being requested. 


In terms of memory footprint, TWiki occupies more memory compared to 
PmWiki. However, PmWiki process is continuously resident in memory since it is 
integrated with Apache server, while TWiki processs is non-resident as the Perl process is 
only invoked upon a page request. In this respect, the results are un-conclusive as the 


memory footprints of both wikis are not grossly disproportionate. 
4. Directory Structure 


Besides memory usage, another important aspect of wikis that must be considered 
in the MLS environment is the directory structure of each wiki engine. As the MLS 


environment enforces a mandatory access control policy, the directory and file structure 
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of the two candidate wiki engines, which are designed for use in a discretionary access 
control environment, must be able to accommodate such access control policy 


enforcement. 


In PmWiki, the wiki pages are stored in the “wiki.d” directory. PmWiki only 
supports one level of sub-directory within the “wiki.d” directory. It does not support a 
hierarchical file structure within the “wiki.d” directory, but is able to support logical 
hierarchical groupings by naming the files according to a structured file naming 
convention that embeds the hierarchical information in the filename itself. The directory 
structure of PmWiki is illustrated in Figure 2 (the texts after the # symbol are comments 


and not part of the file or directory names). 


7 $apache_doc_root 























<7 pmwiki/ 
7 doc/ #documentation 
7 local/ #configuration scripts 
/7 cookbook/ #add-ons 
(7 scripts/ #Pm Wiki scripts 
7 wikilib.d/ #bundled wiki pages 
7 wiki.d/ #wiki pages 
7 Main #main wiki web 
=| Main.Home 
=|Main.RecentChanges 
7 upload/ #page attachments 
Figure 2. PmWiki Directory Structure. 


In TWiki, the wiki pages are stored in the “data” directory. TWiki supports 
multiple levels of sub-directories within the “data” directory. Its logical hierarchical 
grouping is implemented using a corresponding hierarchical directory structure in the file 


system. The directory structure of TWiki is shown in Figure 3. 
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7 $apache_doc_root 























7 twiki/ 
7 bin/ #main scripts 
— lib/ #Twiki library 
7 templates/ #bundle wiki pages 
7 locale/ #languages support 
7 tools/ #tools directory 
7 data/ #wiki pages 
7 Main #main wiki web 

=] WebHome.txt 

=] WebHome.txt,v 
7 pub/ #page attachments 

Figure 3. TWiki Directory Structure. 


In terms of organization of the wiki pages to accommodate the mandatory policy, 
there are two possible approaches. The first is to organize the wiki pages by topic. In 
this approach, wiki pages are grouped by topics, which may consist of contents having 


different classifications. Figure 4 illustrates this approach. 


7 $wiki_doc_root/ 

(7 Naval_platform 

7 Ship 

7 Unclassified 
7 Confidential 
7 Secret 
7 Top_Secret 
<7 Submarine 
7 Unclassified 
7 Confidential 
7 Secret 
7 Top_Secret 





Figure 4. Organization of Wiki Pages by Topic. 


The second approach is to organize the wiki pages by classification. In this case, 


wiki pages are first grouped by classification. Within each classification, the wiki pages 
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are then grouped into different topics. Each topic may appear in one or more 


classifications. Figure 5 shows an example of this approach. 


7 $wiki_doc_root/ 
7 Unclassified 
7 Naval_Platform 
7 Ship 
7 Submarine 
~ Confidential 
7 Naval_Platform 
7 Ship 
7 Submarine 
<7 Secret 
7 Top_Secret 


Figure 5. Organization of Wiki Pages by Classification. 


Because TWiki supports a hierarchical directory structure in the “data” directory, 
it is able to support both approaches. PmWiki, on the other hand, can only support the 
organization of wiki pages by classification due to the fact that it only has one level of 
sub-directories within the “wiki.d” directory. Furthermore, all the PmWiki pages within 
each classification sub-directory will be stored in a flat file structure, differentiated only 
by the filename convention. This is undesirable because STOP OS limits the length of 
filenames to 256 characters, which means that there is a limit on the number of sub- 
directories supported. Furthermore, extremely long filenames complicate the task of file 
administration and housekeeping, since searching and locating such files in a text mode 


oriented user interface is very ineffective. 


In the existing MYSEA testbed environment, the files within the Apache web 
server and the WebDav server are organized by classification. Therefore, the limitations 
of PmWiki do not pose a critical constraint, as the implementation of the wiki engine 
within the testbed environment would be based on a similar file system structure. 
However, TWiki does provide the option for a more intuitive organization of the wiki 
content, i.e., subdirectories within a classification. In this aspect, TWiki is preferred over 


PmWiki. 
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3. Functionalities Design 


In a preceding section, it was shown that PmWiki has a smaller code size 
compared to TWiki. This is in part due to the fact that PmWiki’s design philosophy is 
based on one of simplicity. As such, many functionalities are not included in the default 
installation package, and have to be enabled through additional configuration or 
installation of additional plug-ins. PmWiki and TWiki also differ in the way they 
implement access controls. One of the notable differences is that PmWiki allows 
multiple logins within the same browser session. This may occur when user attempts to 
access a page that his/her current login has no access rights. In such scenario, PmWiki 
will display a login prompt instead of an error message, at which point the user is allowed 
to access the page with another authorized account. However, the login names are not 
displayed anywhere within the wiki page to indicate the current active login. This could 
create confusion regarding the session status, especially if a user holds multiple login 
accounts. However, the most notable difference between the two wiki engines’ access 
control implementation is in the history logging mechanism which keeps track of the 
audit log of all the previous changes in the wiki content. PmWiki allows users to 
arbitrarily specify the author name during the editing session. The history log will then 
display the specified author name, even if this is different from the login name. Hence, 
accountability is not being enforced in PmWiki’s implementation. TWiki, on the other 
hand, enforces one login session per browser. Login sessions are distinguished through 
the display of the login ID on every page request, and the history log entries are bound to 
the identity of the login ID. In this respect, TWiki is considered to be more superior than 


PmWiki. 


E. SELECTION OUTCOME 


Table 2 summarizes the outcome of the selection process between PmWiki and 
TWiki outlined in the preceding paragraphs. Though the results showed that PmWiki has 
a smaller code size and memory footprint, such benefits are offset by the relatively 


inferior way it implements the wiki security-related functionalities such as system login 
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and history logging. Using the selection process, TWiki is deemed to be the more 


suitable choice for implementation in the MYSEA testbed environment. 























S/N Description PmWiki TWiki 
1 Concurrent editing Supported. Supported. More 
robust 
implementation. 
2 Size of executable code 841 KB 2250 KB 
3 Footprint of process memory 4 MB 6 to 13 MB 
4 Directory structure Flat. Hierarchical. 
Supports the Supports both the 
organization of wiki | organization of wiki 
pages by pages by topic and 
classification only. | classification. 
5 Functionalities design Accountability not | Accountability is 
enforced in access strictly enforced in 
control. access control. 














* Shaded box denotes the preferred choice. 


Table 2. Summary of Selection Process. 


F. SUMMARY 


This chapter described the process for the selection of wiki engines. TWiki was 


selected for implementation in the MYSEA testbed. The next chapter will discuss the 


approach and strategy used to implement wiki technology in the MYSEA environment. 
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IV. PROJECT DESCRIPTION 


This chapter explains the concept of operation of the wiki engine in the MYSEA 
test bed environment, and describes the methodology for porting wiki technology to the 


MYSEA testbed. 


A. CONCEPT OF OPERATION 


In the MYSEA testbed environment, users need to be authenticated via the 
Trusted Path Extension (TPE) (also called the Trusted Computing Based Extension 
(TCBE)) before connection to any services in the MLS server is permitted. Following 
identification and authentication, users negotiate a session level from the range of 
security levels for which they are authorized. A user’s maximum session level will be 
bounded by his or her clearance. The session level determines the level of access to data 
that are provided by the services in the MYSEA testbed, including the wiki, through the 
enforcement of MAC policy by the STOP 6.3 operating system. 


Once login is completed, a user can access the wiki via any web browser through 
another wiki login. At this point, the wiki server enforces the wiki-specific DAC policy 
for the wiki session. The user can then read, edit or create wiki pages to which access is 
allowed, as constrained by the DAC policy set on the wiki server, as well as the MAC 
policy enforced by the STOP 6.3 operating system. 


The following three example scenarios illustrate the possible collaboration 


between two users in a multilevel environment. 


Example Scenario 1: Alice and Bob are logged in at the SIM_UNCLASSIFIED 
session level. Both of them can simultaneously edit wiki pages at that level. Alice 
decides that she wants to edit the “MeetingRoomBooking” page, and clicks on the “edit” 
link on the page to insert her schedule. Before she saves her changes, Bob decides that 
he wants to book the same meeting room, and clicks on the “edit” link for the same page. 


He is warned that Alice is currently editing the page, and may choose to proceed with his 
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editing. After both of them have saved their work, the changes to the page will be 
merged. If there is any conflict between the changes, the last person to save will be 
presented with the conflicting sections, and he or she will have to decide on how to 


resolve the conflict. 


Example Scenario 2: Alice is logged in at the SIM_CONFIDENTIAL session 
level, while Bob is logged in with the SIM_UNCLASSIFIED session level. As Alice is 
the secretary of a coalition board meeting, she is uploading the meeting presentation 
materials, which are at the SIM CONFIDENTIAL level. Alice is able to view, but not 
modify, information on the wiki labeled at the SIM_UNCLASSIFIED level. Bob is an 
invited attendee of the meeting, and he is browsing the meeting agenda page at the 
SIM_UNCLASSIFIED level. However, Bob will not be able to see the meeting 
presentation materials uploaded by Alice, which have a security level dominating his 


session level, and will not even know that the upload area exists. 


Example Scenario 3: During the board meeting, Bob was asked to provide some 
documents to the committee. He logs in at the SIM_UNCLASSIFIED session level, and 
uploads the documents to the designated folder. Alice and the other board members who 
are logged in at the SIM_CONFIDENTIAL session level, will be able to read the 
documents uploaded by Bob. 


B. METHODOLOGY 


Following the selection of a wiki engine based on the selection process outlined in 
Chapter III, the implementation of the wiki engine on MYSEA testbed was completed in 
stages to aid in troubleshooting. The implementation began with the installation of the 
wiki engine on RedHat 8.0 Linux on an Intel-based machine, followed by its installation 
on the XTS-400 as a single-level process confined to a single-level domain, and finally 
the wiki was implemented on the XTS-400 server so that it could use the multilevel 
capabilities of the underlying operating system. During each stage, testing was 


performed to ensure that the wiki functionalities were preserved. 
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1. Linux 


For the first stage, RedHat Linux 8.0 was installed as a virtual machine on a HP 
laptop running VMWare as the virtual machine manager. Virtual machine was used in 
order to reduce the amount of hardware resources needed and Redhat 8.0 was chosen 
because the STOP 6.3 operating system of the XTS-400 server provides an environment 
for the execution of RedHat 8.0 Linux-based application programs. The TWiki engine 
required the use of Perl scripting engine, and hence, Perl was installed on the virtual 
machine. For the web server, Apache 1.3.34 was installed as this was the version 
installed on the MYSEA MLS server. The Apache server was configured to be able to 
process the Perl scripts under the wiki directory. The purpose of this stage was to 
become familiar with the installation and configuration process of the required software 
components. Using the Apache and the wiki engine documentation, the software was set 
up without any issues. A few basic functional tests such as listing the wiki topic, 
displaying the topic’s content, editing the topic, creating a new topic, deleting a topic, 
uploading attachments, and setting of access control permissions were performed to 
demonstrated the operation of wiki in a standard environment. After these tests were 
successfully performed, it was decided to proceed to the next stage of the 


implementation. 
2; Single Level Mode on the XTS 


The same versions of an Apache-like server (i.e., Apache modified to be MLS- 
aware) and the TWiki engine were installed to execute in single level mode on XTS 
server. As this stage, the Apache-like web sever was configured to run as a standalone 
server at a single security level. The security level was configured as secrecy level J and 
integrity level 3, which is the security level configured for the network interface card. 
This is needed because in single level mode, all network traffic through the network 
interface card is labeled based on the security level configured for the card. The 
installation and configuration procedures were identical to those of Linux. The same 


basic functional tests were performed to ensure that the wiki worked as intended in the 
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new system. After the tests were completed successfully, the next stage was to adapt the 


wiki to run as a MLS-aware application on the MYSEA server. 
3: Multilevel Mode on the XTS 


In a multilevel environment, the Apache-like web server must be set up as an 
inetd-like service, bound to a specific port and be initiated by the MYSEA Secure 
Session Server (SSS) daemons. The SSS processes behave similarly to the standard inetd 
service in that they listen for new incoming connections and spawn new processes as 
appropriate to handle incoming requests. The difference is that the SSS processes spawn 
new process at the same security and integrity level as the level of the incoming request. 
To set up the multilevel environment, the MYSEA services were configured according to 
the MYSEA Version 2.0 instruction manuals. This was followed by TWiki 
configuration, the majority of which was identical to that of single level environment 
with some additional steps. The additional steps involved setting up two deflection 
directories for storage of temporary files and deleted files, where a deflection directory is 
a directory that exists independently at all security levels simultaneously (see Chapter II). 
The steps also involved creation of various wiki web directories at different security 
levels, and setting of the appropriate files and directory permissions. The detailed design 


and architecture is outlined in Chapter V. 


C. SUMMARY 


This chapter stated the goals of the project, described the concept of operation of 
the wiki, and explained the methodology of porting the TWiki engine to the MYSEA 
testbed. The following chapter will describe the architecture and design of TWiki in the 


context of MLS environment. 
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V. WIKI DESIGN AND ARCHITECTURE 


This chapter outlines the architecture of TWiki for a standard setup and describes 
changes needed to implement it in the MYSEA MLS environment. The chapter also 
documents the issues encountered during the implementation phase and the proposed 


solutions to these problems. 


A. STANDARD TWIKI ARCHITECTURE 


In a standard TWiki setup, the contents of the wiki website are organized into 
webs and topics. A topic is a wiki page. Users can create new topics of their own, and 
edit existing topics according to DAC policy. A web is a collection of related topics. In 
terms of file and directory structures, a web is a sub-directory within the main data 
directory, and a topic is a file within the web sub-directory. For each topic file, there is a 
corresponding version control file that records the change history of the topic. Users can 
also upload and download files to and from the wiki website. These files are stored in the 
pub directory which is organized in a manner similar to the data directory in terms of its 
web sub-directories. Figure 6 shows the file and directory structure of a standard TWiki 


installation. 


Zo 


7 $apache_doc_root 


























7 twiki/ 
7 bin/ #main scripts 
7 lib/ #Twiki library 
7 templates/ #bundle wiki pages 
7 locale/ #languages support 
7 tools/ #tools directory 
7 data/ #wiki pages 
7 Main #home page 
=] WebHome.txt #text content 
=] WebHome.txt,v #version control 
7 TWiki #TWiki documentations 
7 Sandbox #for experimentation and 
testing 
(7 Trash #to store deleted files 
7 pub/ #page attachments 
7 Main #attachments of Main 
7 TWiki #attachments of TWiki 
7 Sandbox #attachments of Sandbox 
Figure 6. TWiki Directory Structure. 


Within the various webs, sub-webs can be created in a hierarchical manner. The 
sub-webs are stored as sub-directories under the web directory. TWiki also requires a 
directory called “twiki” under the /tmp directory to store all temporary files, and a 
directory called “Trash” under the data directory to store deleted files. Figure 7 
illustrates the directory structure of sub-web, where a sub-web called SubDirTest is 


created within the Main web. 


26 


7 $apache_doc_root 






































 twiki/ 
7 data/ #wiki pages 
7 Main #home page 
=] WebHome.txt #text content 
=] WebHome.txt,v #version control 
7 SubDirTest #sub web 
=| WebHome.txt 
=] WebHome.txt,v 
( Trash #to store deleted files 
7 pub/ #page attachments 
7 Main #attachments of Main 
7 SubDirTest #attachments of SubDirTest 
Figure 7. TWiki Sub-Web Directory Structure. 


B. MLS WIKI ARCHITECTURE 


When ported to the MLS environment, the twiki temporary file directory is 
created in the deflection directory of /tmp. This is needed because TWiki stores all its 
temporary files in this single /tmp/twiki directory. Creation of /tmp/twiki in a deflection 
directory ensures that users who login at different session levels will be able to write to 
the /tmp/twiki directory at their respective established levels. The Trash directory is also 
created as a deflection directory for the same reason, because TWiki stores all deleted 
files in a single Trash directory, and therefore a deflection directory would permit file 
deletion at all session levels. As an example, if a user login at the SIM_UNCLASSFIED 
level, the user would be able to see the SIM_UNCLASSIFIED directory and the Trash 
directory at SIM_UNCLASSIFIED. If another user login at the SIM_SECRET level, that 
user would be able to see the SIM_UNCLASSIFIED directory, the SIM SECRET 
directory, and also the Trash directory at SIM_SECRET. Note that since the Trash 
directory is created as a deflection directory, the two users would only see the files 


deleted at their established session level. 


As described in Chapter III, TWiki is able to support the organization of wiki 
content by classification or by topic. For organization by classification, webs 


corresponding to the various security classification levels are created under the data and 
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pub directories at the respective MAC levels. Sub-webs are then created within each of 
these webs to categorize different wiki topics. For organization by topic, webs 
corresponding to each topic of interest are created under the data and pub directories at 
the lowest MAC level (i.e., SIM_UNCLASSIFIED). Sub-webs are then created within 
each of these content webs at the corresponding MAC levels. In this approach, all the 
possible login session levels must be anticipated and the corresponding web directories 
created in advance. Sub-webs within these web directories can be created when required 


by the administrator. 


Figures 8 and 9 illustrate the directory structure for organization by classification 


and organization by topic respectively. 


<7 $apache_doc_root 

LE” twiki/ 
cE bin/ 
C7 lib/ 
“7 templates/ 
cE locale/ 
cE tools/ 
<7 data/ 
C7 Main 
ce TWiki 
<7 Sandbox 
<7 Submarine #SIM UNCLASSIFIED 
<7 SIM UNCLASSIFIED 
<7 SIM_CONFIDENTIAL 
<7 SIM_SECRET 
<7 SIM_TOP_SECRET 
<7 Ship #SIM_UNCLASSIFIED 
<7 SIM UNCLASSIFIED 
<7 SIM_CONFIDENTIAL 
<7 SIM_SECRET 
<7 SIM_TOP_SECRET 











<7 pub/ 


Figure 8. Organization by Topic. 
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<7 $apache_doc_root 

EC” twiki/ 
cE bin/ 
C7 lib/ 
“7 templates/ 
cE locale/ 
cE tools/ 
<7 data/ 
C7 Main 
cy TWiki 
7 Sandbox 
<7 SIM UNCLASSIFIED 
<7 submarine 
<7 ship 
SIM_CONFIDENTIAL 
<7 submarine 
<7 ship 
SIM_SECRET 
<7 submarine 
<7 ship 
<7 SIM_TOP_ SECRET 
<7 submarine 
<7 ship 





Yy 


Yy 








~ pub/ 


Figure 9. Organization by Classification. 


In MLS wiki, users are able to read content with security label equal to or below 
the currently established session level, but only write content with security label equal to 
the currently established session level. If a user inserts a link to a wiki page with a 
security level higher than the session level, the creation of the link will succeed. This is 
because link creation only requires read and write permissions to the working wiki page. 
TWiki will show a question mark “?” beside the newly created link to indicate that the 
target page does not exist. This is the standard TWiki behavior for creating links to any 
non-existent wiki pages, regardless of whether the target page is at the same security 
level or different security level. If the user attempts to access the newly created link, the 
TWiki engine will inform the user that the higher security level web does not exist and 
provide an option to create the web, regardless of whether the link is to a new page or an 
existing page in the higher security level web. If the user attempts to create the web, the 


operation will be denied, as writeup operation is not permitted on the server. 
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C. WIKI ISSUES IN MYSEA 


In the multilevel MYSEA environment, the Apache-like web server runs as part 
of the MYSEA services, which listens to incoming requests and spawns new processes 
running at the same security and integrity levels as the negotiated session level. The 
spawned web server processes also take on the session’s user ID and a specific group ID, 
causing different wiki topics created by different users to be owned by its creator. In the 
standard TWiki configuration, this will not work as the TWiki engine expects the Apache 
server to run as a single user, which is commonly named as apache, such that all wiki 
files are readable and writeable only to the apache user. Hence, only the Apache process 
can read and write to files and directories created by the TWiki engine. The TWiki 
engine then enforces its own access control mechanism to allow TWiki users to set 
permissions on the files they have created. In the MYSEA environment, since the wiki 
files created by the web server processes are owned by their creators, all files, including 
the newly created files, must have read/write permissions set for the group called other 
which is used by the web server. Users must belong to the same group so that they can 
access the files at the OS level. TWiki then enforces the same application-level access 
control mechanism as in the case of its standard implementation. To implement the 
required changes, an attempt was made to change the default permission of new text files 
to 664 (1.e., rw-rw-r--) by setting the wmask to 002 in the /etc/profile script. This works 
for the interactive console logon session, but does not work for the Apache daemon 
process as it does not inherit the wmask setting from the /etc/profile script. It was 
therefore decided that the TWiki code had to be modified to include a umask command to 
change the default permission on new files. Upon modification of the code, the default 


permission on each new wiki file is set to 664. 


However, this introduced a vulnerability, as users could login through an 
interactive shell session and by-pass the TWiki access control to gain direct access to the 


wiki files. For example, a user could establish an interactive session through a program 


30 


such as WebShell to the MYSEA server, and view or modify the content of wiki files 
using an OS command such as cat. The following sections describe possible solutions to 


overcome this limitation. 


D. SOLUTIONS TO THE TWIKI DAC PROBLEM 


To overcome the limitation introduced by the modification of default permissions 
on new TWiki files, two different approaches were investigated. The first approach 
involves restricting the users’ ability to access files through interactive shell sessions, 
whereas the second approach involves the use of the XTS access control list functionality 


to restrict file access. 
1. Restricting Interactive Shell Sessions 


To remove the vulnerability of DAC policy enforcement by-pass and resulting 
direct file access, the user’s ability to launch interactive shell session must be restricted. 
This can done by ensuring that services such as SSH and telnet are not enabled. In the 
MYSEA testbed, SSH and telnet services are not supported, but users are allowed to 
launch interactive shell sessions via the WebShell CGI program. Though the WebShell 
program does not allow the execution of interactive programs such as the vi editor, users 
can still modify the contents of a file by other mechanisms such as output redirection. As 
an example, the command “echo text > myFile” would replace the contents of myFile 


with “‘text’’. 


The WebDAV implementation in MYSEA allows users to navigate to their home 
directory via a symbolic link to the /home directory under the WebDAV document root. 
This also allows users to navigate to the Apache document root, as it is located under 
/home/http/htdocs which is under the /home directory. The users can therefore view and 


edit files under the TWiki data directory using WebDAV. 


As the use of WebShell and WebDAV are part of the overall concept of 


operations of MYSEA, removing these services on the MYSEA server is not a viable 
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solution. However, a separate server can be implemented to only provide wiki services. 
Currently such federation of servers would mean users are required to sign-in more than 
once, but studies investigating single-single-on for the MYSEA testbed have been done 
and a framework for single-sign-on for MYSEA has been proposed [15]. In the separate 
wiki server, WebShell and WebDAV will be disabled, thus removing the direct file 
access capability. For WebShell, this is done by removing the CGI program from the 
cgi-bin directory under the Apache directory. The removal of WebDAV requires 
recompilation of the Apache source code. Another alternative to overcome the WebDAV 
vulnerability in the separate wiki server is to restructure the user home directory such that 
it is located under the WebDAV document root so that the symbolic link to /home can be 
removed. However, this would mean that there is no standardization in the directory 
structure of the servers in the MYSEA testbed as the WebDAV repository on the wiki 
server will be mounted on a different directory root compared to the WebDAV repository 


on other servers, and it is therefore not recommended. 
2. XTS Access Control List 


The STOP 6.3 operating system supports the use of Access Control Lists (ACL). 
Up to seven entries can be added to the ACL for each file or directory, and each of these 
entries can be a combination of user names and group names. The insertion of an entry to 


the ACL is done through the f£sm command [16]. 


A subset of the TWiki access modes can be mirrored using this ACL feature. 
TWiki supports three access modes: view, change and rename for viewing, changing and 
renaming topics or webs, respectively. The view access mode corresponds to the read 
access mode of the STOP OS, whereas the change and rename access modes correspond 
to the write access mode. Therefore, certain granularity will be lost if the XTS ACL 
mechanism is adopted to implement the default TWiki DAC mechanism, since the 
change and rename modes are mapped to the same write permission. Furthermore, the 
revision control file, which is used to generate the history log, will need to have the same 
entries added in the ACL as the topic file itself. This would mean that any authorized 


users of the wiki topic can also modify the history log. The TWiki password file where 
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the hashes of the user passwords are stored will have this vulnerability, although this 
could be mitigated through procedural controls by disallowing password change by the 
user. Specifically, this can be achieved by changing the file ownership of the password 


file to be owned by the administrator. 


The ACLs can be implemented at the directory level or file level. At the directory 
level, authorized users are added to the ACL of the web directory with read and write 
permission through the f£sm command during the web creation process which can only be 
done by the administrator. All files within the directory have owner and group read/write 
permissions enabled. The effect of this is that the user will either have read and write 
permission to all files or to none. It is not possible to have just read permission, as that 
will only restrict the user in terms of disallowing the creation of new file within the 


directory, but the user will still be able to modify existing files. 


At the file level, authorized users are added to the ACLs of each topic file and to 
its corresponding version control file. As users have ability to create their own topics, the 
number of topic files and the associated version control files can be large. It is therefore 
not practical to burden the administrator with the task of adding authorized users to the 
ACLs. Development of new code for insertion and deletion of ACL entries as well as 
modification of the standard TWiki scripts to interface with the newly developed codes 


would therefore be necessary. 


3: Proposed Solution 


The implementation of ACLs at the granularity of the file level for TWiki is not 
recommended for the MYSEA testbed because of the requirement for customization of 
the wiki code. Customization of the wiki code means that the solution is less portable in 
terms of wiki engine maintenance or replacement. The implementation of ACLs at 
directory level for TWiki is also not recommended because the files within the directory 
would need to be group readable and writeable which causes the password file and 
history log files to be vulnerable to misuse. Eliminating interactive shell sessions on a 


separate server dedicated for wiki services is therefore adopted for this study. This 
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solution preserves all wiki functionality and at the same time allows for wiki engine 


upgrades or changes with minimal future modification. 


E. IMPLEMENTATION 


To implement the proposed solution in the MYSEA environment, a second XTS- 
400 server was set up to serve as the standard MYSEA MLS server to test the proposed 


federated design. The test configuration is shown in Chapter VI. 


The directory structure of the wiki server was organized by classification. Several 
directories corresponding to the security levels defined on the MYSEA server were 
created. Figure 10 shows the directory structure within the data directory with the 
security label of the various sub-directories denoted using comments after the # symbol. . 


The pub directory was configured with a similar directory structure. 











~& data/ #SIM_UNCLASSIFIED 
<7 Main #SIM_UNCLASSIFIED 
7 TWiki #SIM_UNCLASSIFIED 
<7 Sandbox #SIM_UNCLASSIFIED 
<7 Trash #deflection directory 
<7 SIM_UNCLASSIFIED #SIM_UNCLASSIFIED 
7 SIM_CONFIDENTIAL #SIM_CONFIDENTIAL 
7 SIM_SECRET #SIM_SECRET 
7 SIM_PACIFIC_SECRET #SIM_PACIFIC_SECRET 
<7 SIM_NATO_SECRET #SIM_NATO_SECRET 
7 COALITION_COMMAND  #COALITION_COMMAND 
<7 SIM_TOP_SECRET #SIM_TOP_SECRET 
Figure 10. Directory Structure. 


The data and pub directories, and all the sub-directories within them, were created 
with file permissions of 775, i.e., owner and group have full permissions, while others 
only have read and execute permissions. This allows existing files to be read and new 
files to be created by members belonging to the group. All files under data and pub have 
file permissions of 664, i.e., owner and group have read and write permissions while 


others only have read permission. 
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In order for new webs and topics created by the wiki engine to have the same 
permission settings described above, the source code of the wiki engine was modified as 
described in Section C of this chapter. In particular, a “umask=002” command was 
inserted in two Perl modules of the TWiki engine, namely manage.pm and save.pm, 


which contain code to create new webs and new topics, respectively. 


In terms of server configuration, the WebDAV module was removed via 
recompilation of Apache source code. The WebShell GGI script was also removed from 
the cgi-bin directory so that users can no longer execute any interactive shell session on 


the wiki server. The server configuration procedures are described in Appendix A. 


F. SUMMARY 


This chapter described the design of a standard TWiki installation, and the design 
and architecture of the TWiki integration into the MYSEA environment. The issues 
encountered were discussed, and various solutions were presented. The proposed 
solution is to implement the wiki engine on a separate server with the interactive shell 
session disabled. The next chapter will describe the testing procedures and the results of 


the tests. 
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VI. TESTING AND RESULTS 


This chapter describes the test plan and the testing results for the use of TWiki in 
the MYSEA testbed. There are four parts to the testing: functional test, DAC security 
test, MAC security test and integration test. Functional testing is required to confirm the 
expected functionalities of the wiki engine and provides a baseline measurement on the 
ability of the system to perform its task under a specific environment. The functional 
tests performed fall into three configuration categories: Linux, single level XTS and 
multilevel XTS. DAC security tests were performed for all configurations to verify that 
the DAC policies are being enforced correctly. MAC security tests were also performed 
for the single level XTS and multilevel XTS configurations to verify that the MAC 
policies are being enforced correctly. Integration testing is required to verify that the 
federated wiki server is able to function correctly in the MYSEA environment, and that 


users are able to use MYSEA services available on both servers. 


The test topology consisted of a simple standalone network with two XTS-400 
servers, a Windows XP client desktop and a Windows XP client laptop, all connected via 
a network hub. Both client machines are capable of running virtual machines through 
the VMWare Server installed on the clients. Testing was done through the Internet 
Explorer browser on the Windows XP client and the FireFox browser on the Linux 
virtual machine running within the VMWare Server on the Windows XP client. Figure 


11 shows the network topology of the test setup. 
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Windows XP 


Client 1 
TPE1 (only used in —_——. 
multilevel testing) 


Windows XP 
Client 2 








TPE2 (only used in 
multilevel testing) 





MLS Wiki Server MYSEA MLS Server 
-TWiki -WebDAV 
-WebShell 
Figure 11. Network Topology of Test Setup. 


A. FUNCTIONAL TEST PLAN 


Functional tests were performed on the three test configurations (Linux, single 
level XTS, and multilevel XTS). The tests were done to ensure that the wiki engine work 
as intended in the specific environment. The functional tests can be broadly categorized 
into three types: read, write and administration. The read tests involve reading wiki 
pages through the TWiki engine via the list, display and download capabilities. The write 
tests involve writing wiki pages through the TWiki engine via the edit, create, delete and 
upload functions. Administration type tests involve performing administrative tasks. 
These tests include configuring the TWiki engine, setting permissions of the wiki 
contents, and registering new user account. Two TWiki test user accounts, TestUser] 
and TestUser2 were used for concurrent testing in test cases Al to A9. The objective is 
to ensure that two users logged in from two client machines can view and modify 
different files at the same time. Table 3 lists the various functional tests that were 


performed. 


38 


PE [ane | sca [rs 
# Test Type Test Objective Setting | Setting 


Ensure that user can edit wiki pages 
Ensure that user can create wiki pages 
Ensure that user can delete wiki pages 


Simultaneous |Ensure that multiple users can safely edit 

Setting Ensure that user can change access rights of 
Ensure that administrator can configure 
Ensure that guest can register for login 


Table 3. List of Functional Tests. 





B. LINUX TESTING 


The functional tests performed on Linux served as a baseline for the functionality 
for a TWiki server. In other words, if a functionality does not work in the Linux 


environment, it is not expected to work in the XTS environment. 
1. TWiki DAC Test Plan 


TWiki DAC tests were performed to ensure that the TWiki DAC policies were 
being enforced correctly. The TWiki DAC test plan includes test cases involving the 
three permission modes enforced by TWiki: view, change and rename modes. For each 
mode there are four settings: DenyTopic, AllowTopic, DenyWeb and AllowWeb. Table 


4 shows the permitted values and the processing rules for each of the settings. 
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Setting Permitted values Processing Rules 


DenyTopic not set (i.e. deleted or commented out) not evaluated 


comma-delimited list of Users and Groups __|people in the list will be denied 


AllowTopic [not set (i.e. deleted or commented out) 
empty 
comma-delimited list of Users and Groups 


enyWeb |not set (i.e. deleted or commented out) 
empty 
comma-delimited list of Users and Groups 
AllowWeb not set (i.e. deleted or commented out) 
empty 
comma-delimited list of Users and Groups 





not evaluated 
equivalent to not setting 


people in the list will be allowed, people NOT in 
the list will be denied 
not evaluated 


equivalent to not setting 
people in the list will be denied 
not evaluated 

equivalent to not setting 


people in the list will be allowed, people NOT in 
the list will be denied 


Table 4. Permitted Values and Processing Rules of TWiki DAC Settings. 


From Table 4, it can be seen that for DenyTopic setting, there are three possible 
permitted values (not set, empty and list of users/group). For each of the other three 
settings (AllowTopic, DenyWeb and AllowWeb) there are two possible permitted values, 
since an empty value is equivalent to not setting any value. Therefore, there are 24 
different possible setting combinations involving the view, change and rename 


permission modes. 


In evaluating the DAC settings, note that TWiki DAC enforcement mechanism 
adheres to the rules showed in Table 5 in the listed order (i.e., evaluation starts from the 
top of the list; if a rule is met, then it is applied immediately and no other rules are 
considered). The three modes: view, change and rename may be granted or denied 


separately [17]. 
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TWIKI DAC Rules 
If the user is an administrator access is PERMITTED. 


user names 
(i.e. Set DENYTOPIC = ) denied access to this topic.. 


everyone else is DENIED 
user names 
wikinames everyone else will be DENIED 


If none of the above rules match access is PERMITTED. 





Table 5. Order of TWiki DAC Rule Evaluation (After [17]). 


In formulating the DAC test plan, all the 24 possible combinations of setting the 
TWiki DAC were considered. Two additional scenarios were also considered: one for 
explicitly testing administrator permissions, i.e., Rule 1 of Table 5, and the other to 
ensure TWiki DAC does not override OS DAC. Table 6 shows an example of the 26 
different scenarios. Six out of the 26 scenarios were shortlisted as candidates to verify 
that both the processing rules and the order of rule evaluation are being enforced as stated 
in Table 4 and Table 5. The six scenarios were selected such that when a particular mode 
is set (e.g., DenyView), the next mode with an opposite effect (e.g., AllowView) at a 
lower order of evaluation would be set. This is to ensure that TWiki stops evaluating 
other rules once a rule is matched, and any other lower priority rules have no effect. For 
example, in Test Scenario 4 (S/N. 10) AllowTopic and DenyWeb are both set to 
TestUserl. From Table 5, TestUserl will match Rule 4 (AllowTopic), and will be 
granted access. Although DenyWeb is also set to TestUser1, it should have no effect as it 
will not be evaluated by TWiki. This approach verifies that the order of rule evaluation is 
correctly enforced, and the six scenarios ensure that Rules 2 to 7 of Table 5 are verified. 
Besides the six scenarios, the two scenarios for testing of administrator permissions, 1.e., 
to verify Rule 1 (S/N. 25 of Table 6), and testing that TWiki DAC does not override OS 
DAC (S/N. 26 of Table 6) were also considered. Out of these eight candidate scenarios, 


4] 


five exception cases where users are expected to be denied access were chosen as final 
test scenarios. The other three candidates were not chosen as test scenarios because all 


their results are expected to pass. 


For the five selected test scenarios, test cases for the view, change and rename 
modes were formulated for the Linux, single level, and mulitlevel configurations. The 
view, change and rename test cases were distributed among the five test scenarios. The 
results from the Linux test cases were used for establishing a baseline for the expected 
results. In each of the test cases, three test instances, each involving a different user 
accounts were performed. The user accounts were: TestUserl, TestUser2 and 
AdminUser. TestUser2 was mainly used to verify the processing rules of AllowTopic 
and AllowWeb, where a user listed in the rules (i.e., TestUser1) is allowed access and all 
others (i.e., TestUser2) are denied. These test cases are designed to verify that the TWiki 
DAC policies are enforced in accordance to TWiki documentation. Table 7 shows the 
various test scenarios and test cases selected for testing, and the total number of test 
instances performed. Windows Internet Explorer client was used for the test cases of the 
first three scenarios, while Linux FireFox client was used for test cases of the last two 


scenarios. A total of 57 test instances comprised the TWiki DAC testing. 
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a 

a a a Oa 
Ee eT OE! ETT] TE TT 
psf empty] Pass 3)] Pass (3) Pass(DP 
Pp af CT Testsertf | Pass (4) Fail (4) Pass(P 
psf CT Testtsert{ TestUsert] Fail (2)| Fail (4)|__Pass (1)|Selected as Test Scenario 1 to test the exception. __| 
poof Tt Testtsert{ empty] Pass (3) Pass (3)| Pass) 
Pm Testtsertf Fail (S| Pass] Pass 
Po sf | Tresttsert{ | TestUsert] Fail (2)|_ Pass(7)| Pass} 
p of CT TestUsert] | empty] Pass (3)| Pass (3)| Pass (1)|Not selected as all are expected to pass. | 
| tof Testsert TestUserif | Pass (4)] Fail (4)|___ Pass (1)|Selected as Test Scenario 2 to test the exception. __| 
pif Tresttsert| TestUseri{ __TestUser!] Fail (2)| Fail (| Pass()P 
| ia] | Testtseri| TestUseri{ empty] Pass (3) Pass (3)|_— Pass) 
| 13] TestUsert{ | Pass (6)| Fail (6)| Pass (1)|Selected as Test Scenario 3 to test the exception. _| 
| 14] TestUsert{ | TestUsert] Fail (2)] Fail (| Pass)P 
| is{ TestUsertf | empty Pass (3)] Pass (3)| Pass(DP 
| lof TestUsert[ | TrestUsert] | Pass (4) Fail 4] Pass(P 
| 17] TestUsert{ | TestUsert{ TestUser!] Fail (2)|_ Fail] Pass()P 
| is] TestUser!{ | TestUseri{ empty] Pass (3)|_ Pass (3)|Pass()P 
| 19 TestUserl| —TestUser!{ | | Fail (S)| Fail (6)|___ Pass (1) Selected as Test Scenario 4 to test the exception. _| 
| 20] TestUser!| _—TestUser!{ | TestUsert] Fail (2)| Fail (| Pass} 
| 2i[  Testtser!| _—TestUser!{ | empty] Pass (3)| Pass (3)|—Pass()P 
| 22{ TestUserl| _—TestUserl| _—TestUserl| | Pass (4) Fail (4)|—Pass(DP 
| 23{ TestUserl| __—TestUser!| __—TestUserl| __—TestUser!| Fail (2)| Fail (4 Pass([_O 
| 24] TestUserl| —TestUserl| __—TestUserl{ empty! Pass (3)|_Pass(3)|_—Pass()P 
p 25f | AdminUser| | AdminUser] Pass (7)|__Pass (7)|__Pass (1) |Not selected as all are expected to pass. 
| of TY Testusert fail (NA)] Fail (NA) Fail (NA) Selected as Test Scenario 5 to test the exception. __| 


* number in bracket denotes active rule for the subject. 
- " denote not set. 











Table 6. — Possible Combination of TWiki DAC Setting. 
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one subj) per 
Scenario per 
Configuation 


V 
Linux VO 
Linux (CT 
= 
Multilevel [CO 
Linux (RT 
= — 
Multilevel [Multilevel |[R | 
Total Number of Test Instance to be Performed 


FF - FireFox 
IE - Internet Explorer 


V(E) - View at Read Equal (only for XTS 400) 
V(D) - View at Read Down (only for XTS 400 





Table 7. Test Scenarios and Test Cases Performed. 


Based on the test cases identified, TWiki DAC test plans were formulated for the 
view, change and rename permission mode. Except for test cases BL4, BL5 and BL6, the 
default OS DAC for the TWiki test files used in other test cases were set with standard 
Unix permission bits [22] of 664, i.e., read/write for owner and group, and read only for 
others. For test case BL4, permission bits of the file were set to 000, i.e. nobody has read 
or write permission. For test case BLS, permission bits of the file were set to 444, Le., 


everyone has read-ony permission. For test case BL6, permission bits of the directory 
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containing the file were set to 555, i.e. nobody can write to the directory and hence the 
files within the directory cannot be renamed. Table 8 shows the various TWiki DAC 


tests that were performed. 


BA TWiki DAC: VIEW Permission Mode Setting Exp ce Results ier Subject: 
Test Tvpe AllowWeb |DenyWeb ae oe 
| BLI[TWikiDenyTopicView | TY TeestUser I] TestUser!] Faill Fail Pass 


a BL2 ensures s that a user is not able to read wiki page that — access er throug 


oie ee pa a et HDT, 
az 


Test BL4 ensures that a user is able to read wiki page that has access granted throug 


PBLS|TWiki AllowWebChange [ TestUserl] ] TT Pass] Fal) Pass 
= 


Test BL6 ensures that a user is is to ad wiki page with access granted throug 


PBLATWikiDenyWebRename [ TestUserl[ TestUserl] J] | Falll_—Falll Pas 


es BLS ensures that a user is not rable to read wi page that has access denied through DonWon 


TWiki View DAC Not TestUser1, 
BLSjoverriding OS DAC TestUser2 Fail Fail| Fail] 


| [Test BLS ensures that TWiki View DAC does not overwrite OS DAC (file permission bit set to 000) 


ee Change DAC Not TestUser1, 
— overriding OS DAC TestUser2 Fail Fail Fail 


|__| Test BL6 ensures that TWiki Change DAC does not overwrite OS DAC (file permission bit set to 444) 


TWiki Rename DAC Not TestUserl1, 
Eel overriding OS DAC TestUser2 Fail Fail Fail 


|_| Test BL7 ensures that TWiki Rename DAC does not overwrite OS DAC (directory permission bit set to 555) 





Table 8. Linux TWiki DAC Test. 


2. Test Results 


All tests performed successfully. Table 9 shows the results of the Linux functional 


rest! teerType FRG ee pee ee 
Test#| __Test Type 


tests. 





Table 9. Linux Server Functional Test Results. 
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Table 10 shows the results of the Linux TWiki DAC testing. The results show 
that all the wiki operations on the clients behaved as expected when constrained by the 


TWiki DAC policy. 


ao a ee eee 
: Test Type 


TWki View DAC not 
TWki Change DAC not 
TWki Rename DAC not 





Table 10. Linux Server DAC Test Results. 


C. SINGLE LEVEL XTS TESTING 


The tests outlined in this section were performed on the single level XTS server. 
The objective was to ensure that no functionality was lost during the transition from 
Linux server to the single level XTS server, and that the DAC and MAC security 


constraints were met. 


1. TWiki DAC Test Plan — Single Level Configuration 


Another set of TWiki DAC tests were performed to ensure that the TWiki DAC 
policies were being enforced correctly in the single level XTS configuration. The 
security labels of the test subjects and objects were set such that all test operations were 
allowed with respect to MAC policy. Table 11 shows the various TWiki DAC tests that 


were performed. 
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Test TWiki DAC: VIEW Permission Mode Setting Expected Results for Subject: 
# |Test Type AllowWeb |DenyWeb_|AllowTopic|DenyTopic | Subject Level| Object Level| Operation 


Ea Tests BS1 ensures that a user is not able to read wiki page that has access denied through DenyTopicView. 


| [Test BS2 ensures that a user is able to read ma page that as access granted through Allewrapie views 


| [Test BS3 ensures that a user is able to read wiki page with access granted through Allon Web View 


| [Test BS4 ensures that a user is not able to aT wiki page that has access denied through Deny WebWiew. 


TWiki View DAC Not TestUser1, 
a overriding OS DAC TestUser2 s11:i13 sl1:il3] Read equal Fail Fail Fail 


| ‘| Test BS5 ensures that TWiki View DAC does not overwrite OS DAC (file permission bit set to 000) 


TWiki Change DAC Not TestUserl1, 
— overriding OS DAC TestUser2 sl1:i13 sl1:i13] Write equal Fail Fail Fail 


| [Test BS6 ensures that TWiki Change DAC does not overwrite OS DAC (permission bit set to 444) 





Table 11. Single Level XTS TWiki DAC Test. 
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2. MAC Test Plan — Single Level Configuration 


MAC tests were performed to ensure that the MAC policies were enforced 
correctly. The MAC test cases involve reading and writing at different security levels. 
Since every user running on the single level XTS server is bound to a single security 
level, i.e., sl1:113, only variance in the object security level can be tested. Table 12 


shows the MAC tests that were performed. 


TWiki Ree VIEW & CHANGE 
Permission Mode Ree 
Expected Result 
snd Deny |Allow DenyT|Subject {Object for Subject: 
Test # |Test Type Web __|Topic opic {Level Level |Operation |TestUser1 


Secrecy Read Up eer sH:il3__[sl2:i13 
Test CS1 ensures that a user is not able to read wiki page at a secrecy level higher than the level of the currently 
established session. 


|CS2__[SecrecyReadDown | {| fTestUserl | -fsit:il3[sl0:i13_[Read_ [Pass 


= Test CS2 ensures that a user is able to read wiki page at a secrecy level lower than the level of the currently 


established session. 


Secrecy ReadEqual | | -TestUserl | {sit:il3__[si1:il3 
Test CS3 ensures that a user is able to read wiki page at a secrecy level equal to the level of the currently 
established session. 


ICS4__ [Secrecy WriteUp |] TestUserl | -fsttsil3[si2:i13_ [Write [Fail 


Test CS4 ensures that a user is not able to write to wiki page at a secrecy level higher than the level of the 
currently established session. 


ICS5__[Secrecy WriteDown | | fTestUserl | -fstt:il3[si0-i13_ [Write Fail 


Test CS5 ensures that a user is not able to writeto wiki page at a secrecy level lower than the level of the 
currently established session. 


ICS6_[Secrecy Write Equal |] {TestUserl | fsttsil3[stt:il3 [Write Pass 


Ss Test CS6 ensures that a user is able to write to wiki page at a secrecy level equal to the level of the currently 





established session. 





Table 12. Single Level MAC Test. 


a Test Results — Single Level Configuration 


Table 13 shows that the results of the functional test on single level XTS were the 
same as those of Linux server. This shows that no functionality was lost during the 


transition to single level XTS. 
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Internet Explorer 
Test # Test Type TestUserl |TestUser2 |TestUserl |TestUser2 


Table 13. Single Level XTS Functional Test Results. 





Table 14 shows the results of the single level XTS TWiki DAC testing. The 
results show that all the wiki operations on the clients behaved as expected when 


constrained by the TWiki DAC policy. 


Tost 
: Test Type __|TestUserl [TestUser? [AdminUser [TestUserl [TestUser? [AdminUser 


TWki View DAC not 
TWki Change DAC not 


Table 14. Single Level XTS TWiki DAC Test Results. 





Table 15 shows the results of the single level XTS MAC testing. The results 
show that all the clients behaved as expected when constrained by the MAC policy. 
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Internet 
Test # |Test Type Explorer |FireFox 





Table 15. Single Level XTS MAC Results. 


D. MULTILEVEL XTS TESTING 


The tests outlined in this section were performed on the XTS server operating as a 
multilevel MYSEA server. The objective was to ensure that no functionality was lost 
during the transition from the single level XTS configuration to the multilevel MYSEA 


configuration, and that the TWiki DAC and MAC security constraints were met. 


1. TWiki DAC Test Plan — MLS Configuration 


Another set of TWiki DAC tests was performed to ensure that the TWiki DAC 
policies were being enforced correctly in the multilevel MYSEA configuration. Table 16 


shows the various TWiki DAC tests that were performed. 
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Test TWiki DAC: VIEW Permission Mode Setting Expected Results for Subject: 
# |Test Type AllowWeb |[DenyWeb_|AllowTopic|DenyTopic Session Level Object Level Operation TestUser2| AdminUser| 


SIM_] SIM 


| _|Tests BMI ensures that a user is not able to read wiki page that es access denied through DenyTopicView 


SIM_|] 


= Test BM2 ensures that a user is able to read Mild p page that Tass access granted through AllowTopicView. 


SIM 


| _ [Test BM3 ensures that a user is able to read wiki page with access granted through AllowWebView. 


SIM 


Test BM4 ensures that a user is not able to rl wiki page that has access denied through DenyWebView. 


TWiki View DAC Not TestUser1, SIMI 
BM5Sloverriding OS DAC TestUser2| UNCLASSIFIED Frc rs Read equal Fail Fail Fail 


Test BMS5 ensures that TWiki View DAC does not overwrite OS DAC (file permission bit set to 000) 


TWiki Rename DAC Not TestUser1, SIM SIM 
BM6overriding OS DAC TestUser2| _UNCLASSIFIED] _UNCLASSIFIED] Write equal] Fail] Fail Fail 


| __|Test BM6 ensures that TWiki Rename DAC does not overwrite OS DAC (directory permission bit set to 555) 


























Table 16. Multilevel XTS TWiki DAC Test. 
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2: MAC Test Plan — MLS Configuration 


MAC tests were performed to ensure that the MAC policies were being enforced 
correctly. The MAC test cases involve reading and writing object with a security level 
equal to, above and below the established session level. Table 17 shows the MAC tests 


that were performed. 


TWiki DAC: VIEW & CHANGE Expected 
Permission Mode Setting Result for 
Test #_|Test Type Web [Web {Topic Topic |Session Level Object Level Operation |TestUserl 


Secrecy Read SIM_ 
Up TestUser1 UNCLASSIFIED |SIM_SECRET Read Fail 


me. CM1 ensures that a user is not able to read wiki page at a secrecy level higher than the level of the currently 
le session. 


Secrecy Read 
Down TestUser1 SIM_SECRET eee Read Pass 


Test CM2 ensures that a user is able to read wiki page at a secrecy level lower than the level of the currently established 
session. 


Secrecy Read SIM_ 
Equal TestUser1 UNCLASSIFIED |SIM_SECRET Read Pass 


fe ee CM3 ensures that a user is able to read wiki page at a secrecy level equal to the level of the currently established 
i ee 


Secrecy Write SIM_ Ls 
CM4_ |Up TestUser1 UNCLASSIFIED ECHbENTA Write Fail 


Test CM4 ensures that a user is not able to write to wiki page at a secrecy level higher than the level of the currently 
established session. 


Secrecy Write SIM_UNCLASSI 
CMS {Down TestUser1 SIM_SECRET FIED Write Fail 


Test CMS ensures that a user is not able to writeto wiki page at a secrecy level lower than the level of the currently 
established session. 


Secrecy Write SIM_ SIM_ 
CM6__ |Equal TestUser1 UNCLASSIFIED |UNCLASSIFIED | Write Pass 


Test CM6 ensures that a user is able to write to wiki page at a secrecy level equal to the level of the currently established 


Write Pass 

Read Fail 
Test CM7 ensures that although a user is able to create a link pointing to wiki page with a secrecy level higher than the 
level of the currently established session, the user is not able to view or create that 





Table 17. Multilevel XTS MAC Tests. 
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3. Test Results — MLS Configuration 


Table 18 shows that the results of the functional tests on the multilevel XTS 
configuration were the same as those of the Linux server and the single level XTS 
configuration. This shows that no functionality was lost during the transition to 


multilevel XTS. 


Internet Explorer 
Test # Test Type TestUserl |TestUser2 |TestUserl |TestUser2 


Table 18. Multilevel XTS Functional Test Results. 





Table 19 shows the results of the multilevel XTS TWiki DAC testing. The results 
show that all wiki operations on the clients behaved as expected when constrained by the 


TWiki DAC policy. 


i ee ee 
: Test Type 
on 
ae 
_ 





TWki View DAC not 
TWki Rename DAC not 
si 


Table 19. Multilevel XTS TWiki DAC Test Results. 
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Table 20 shows the results of the multilevel level XTS MAC testing. The results 
show that all wiki operations on the clients behaved as expected when constrained by the 


MAC policy. 


Internet 
Test # |Test Type Explorer |FireFox 


Secrecy Write Equal & Read |Write Pass |Write Pass 
CM7_ |Up Read Fail _}|Read Fail 





Table 20. Multilevel XTS MAC Test Results. 


E. INTEGRATION TEST PLAN 


Integration testing was performed to verify that the federated wiki server was able 
to function correctly in the MYSEA environment, and that the users were able to use the 
services provided by the two MYSEA servers. The test involved the user switching 
between the WebDAV services running on one server and the wiki services running on 
another server and then verifying that those services continued to function correctly for 


the user. Table 21 shows the two tests that were performed. 


Test Type Expected Result |Test Objective 
Use Wiki on Server X 





Use WebDAV on Server Y Ensure that user can access WebDAV on server Y 


Table 21. Lists of Integration Test. 
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1. Test Results 


Table 22 shows that the TWiki server can integrate with the existing MYSEA 
testbed environment as users were able to switch between the WebDAV and wiki 
services on different servers without losing any functionality. However, users must 


perform two separate logins as the two servers are not fully federated. 


Test Type Internet Explorer 


Use Wiki on Server X 
Use WebDAV on Server Y 


Table 22. Multilevel XTS Integration Test Results. 





F. SUMMARY 


This chapter outlined the functional, TWiki DAC, MAC and integration tests 
performed on three stages of the wiki implementation: Linux, single level XTS, and 
multilevel XTS. It also summarized the test results, which were consistent with the 
expected results. The next chapter will discuss the conclusion of the work performed, 


and suggest possible future work in related areas. 


a) 


THIS PAGE INTENTIONALLY LEFT BLANK 
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VII. CONCLUSION AND FUTURE WORK 


This chapter states the conclusion of the thesis, discusses a related project and 


suggests possible future work. 


A. CONCLUSION 


The goals of this thesis were to determine whether it is possible to design a wiki 
architecture for a MLS environment, and if so to demonstrate the implementation of such 
a MLS wiki in the MYSEA testbed. These goals have been successfully demonstrated 
through the implementation of TWiki on a separate MLS server in the MYSEA testbed. 
The tests described in Chapter VI confirmed that the MLS-aware wiki server is fully 
functional and is properly constrained by the underlying MAC and DAC policies 
enforced by the STOP OS. 


B. RELATED WORK 


Galois Inc. has a cross-domain solution called the Trusted Services Engine (TSE) 
that implements WebDAV on a MILS separation kernel to provide WebDAV 
functionality similar to the MYSEA WebDAV server [18]. Galois Inc. is also working 
on wiki services for their cross-domain solution. The details of their cross-domain wiki 
services are not publicly available, but it is understood that Galois plans to construct a 
wiki with features such as read down and cross-domain merge [19]. The wiki server in 
MYSEA as presented in this thesis supports read down capability, but a cross domain 


fusion capability is left for future work. 


sy 


C; FUTURE WORK 


The following issues of arose from this study and warrant additional further 


work. 


1. Wiki Password Synchronization 


TWiki maintains its own database of user IDs and passwords. Currently, there is 
no synchronization between the XTS system’s IDs and passwords, and TWiki’s IDs and 
passwords, and users are required to maintain two separate sets of IDs and passwords. A 
single sign-on solution would provide a more usable interface for the users in terms of 


user ID and password maintenance and thus enhance the user experience. 


2. Cross Domain Content Merge 


Cross domain content merging would enable users to login at different session 
levels to see relevant contents up to their established level, instead of having to browse to 
individual directories at different security levels to view the content at each level 
separately. Such a capability would present users with a more unified view of related 


contents within the wiki, thus enhancing both the user experience and user productivity. 


3: Removal of SMTP and IMAP Services on Wiki Server 


The SMTP and IMAP services running on the MYSEA server allow mail 
applications to establish connections to the server. With the additional wiki server, user 
will have multiple sets of mailboxes, one for each server. This creates usability issues as 
users must maintain and manage separate sets of mailboxes. The SMTP and IMAP 
services could be removed by reconfiguration of the MYSEA secure session services to 


further enhanced the security of the wiki server. 
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APPENDIX A: INSTALLATION PROCEDURES 


This appendix outlines the installation procedures for the TWiki 4.1.2 wiki engine 
on RedHat Linux 8.0, single level XTS, as well as multilevel XTS. 

The following instructions make reference to the Secure Attention Key (SAK) of 
the XTS-400 machine, which is invoked by simultaneously pressing the “alt” and the 
“SysRq”’ (a.k.a. Print Screen) keys. The SAK establishes a trusted path and allows 
trusted commands to be executed. Two trusted commands are used frequently and are 
therefore mentioned here: the s1 command and the fsmcommand. The si command is 
used to set the security level of the user session, and the £sm command is used to display 


and change the MAC and DAC properties of the files and directories. 


A. INSTALLATION AND TEST TOPOLOGY 


The test setup consists of two XTS-400 servers running STOP OS 6.3 and two 
Windows XP clients, connected via a dedicated network hub, as shown in Figure 12. The 
Windows XP client has Internet Explorer 6 browser installed which is used as the client 
software for accessing the TWiki engine. Special TPE software written to run on a 
desktop is also installed on the client to allow user to login to XTS-400 server. 

The MYSEA wiki installation CD is needed to perform the installation 


procedures. 
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Windows XP 
Client 1 


(192.168.0.160) 


Windows XP 
Client 2 


(192.168.0.140) 





Bi Bi 
hh» Pn 


TPE1 (only used in, ) TPE2 (only used in 


multilevel testing) multilevel testing) 
Hub 










MLS Wiki Server MYSEA MLS Server 
-TWiki -WebDAV (192.168.0.131) 
(192.168.0.130) -WebShell 
Figure 12. Test Setup Network Topology. 


B. LINUX INSTALLATION 


The procedures outlined in this section are to be performed as a root user on a 
machine running RedHat 8.0 Linux. RedHat 8.0 is used because the XTS-400 STOP 6.3 
operating system is binary compatible to it. These procedures will copy the source code 
from the wiki installation CD, install and configure the Apache web server and the TWiki 
4.1.2 wiki engine on the server. In this section, a base installation of perl scripting engine 


is assumed. 


Step 1. Copy the Apache web server, the required Comprehensive Perl Archive 
Network (CPAN) modules, and the TWiki wiki engine from the MYSEA wiki 
installation CD: 


mount /dev/cdrom /mnt/cdrom 

cd /root 

ep /mrt/edrom/apaché_1.3.34.tar.gz «/ 
60 


cp /mnt/cdrom/TWiki-4.1.2.tgz ./ 

cp /mnt/cdrom/CPAN/perl-Error-0.15-2.0.rh8.dag.noarch.rpm ./ 
cp /mnt/cdrom/CPAN/perl-FreezeThaw-0.43 
O.dag.rh80.noarch.rpm ./ 
































cp /mnt/cdrom/CPAN/perl-Time-modules-—2003.1126- 
1.0.rh9.rf.noarch.rpm ./ 

cp /mnt/cdrom/CPAN/per1l-DBI-1.40-5.i386.rpm ./ 

cp /mnt/cdrom/CPAN/perl-DB_File-1.804-55.i386.rpm ./ 

cp /mnt/cdrom/CPAN/perl-—CGI-Session-4.00_08- 
1.0.rh9.rf.noarch.rpm ./ 

cp /mnt/cdrom/CPAN/per1-CGI-2.81-88.3.i386.rpm ./ 











cp /mnt/cdrom/CPAN/libpng10-1.0.13-5.1386.rpm 





cp /mnt/cdrom/CPAN/gd-1.8.3-4.1386.rpm ./ 
cp /mnt/cdrom/CPAN/perl-GD-1.41-0.rh80.dag.i386.rpm ./ 


















































cp /mnt/cdrom/CPAN/perl-HTML-Tagset-—3.10-1.rh9.rf.noarch.rpm 
he 

cp /mnt/cdrom/CPAN/perl-HTML-Parser-3.55-1.rh9.rf.i386.rpm 
af 

cp /mnt/cdrom/CPAN/perl-HTML-Tr 3.17-0.dag.rh80.noarch.rpm 
sof 


Step 2. Install the required CPAN modules: 


rpm —-ivh perl-Error-0.15-2.0.rh8.dag.noarch.rpm 
rpm —ivh perl-FreezeThaw—-0.43-0.dag.rh80.noarch.rpm 
rpm —-ivh perl-Time-modules-—2003.1126-1.0.rh9.rf.noarch.rpm 
rpm —-ivh perl-DBI-1.40-5.i386.rpm 
rom -ivh perl-DB_File-1.804-55.1386.rpm 
rem —-ivh perl-CGI-Session-4.00_08-1.0.rh9.rf.noarch.rpm 
rpm —ivh perl-CGI-2.81-88.3.i1386.rpm 
rem -ivh libpngl10-1.0.13-5.1386.rpm 
rpm -ivh gd-1.8.3-4.1386.rpm 
rpm -ivh perl-GD-1.41-0.rh80.dag.i386.rpm 
rpm —-ivh perl-HTML-Tagset-—3.10-1.rh9.rf.noarch.rpm 
p 
Pp 
























































rpm —ivh 1-HTML-Parser-3.55-1.rh9.rf.1i1386.rpm 
rpm —ivh 1-HTML-Tr 3.17-0.dag.rh80.noarch.rpm 

















Step 3. Unpack, build and install the Apache web server: 


tar -zxvf apache_1.3.34.tar.gz 
cd /root/apache_1.3.34 
./configure —-prefix=/www 

make 

make install 
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Step 4. Save and edit the default Apache configuration: 


cd /www/conf 
cp httpd.conf httpd.conf.bak 
vi httpd.conf 














Step 5. Append the following lines to the “http.conf” file: 


A 





Directory /www/htdocs/twiki/bin> 
Options ExecCGI FollowSymLinks 
Order allow, deny 
Allow from all 
SetHandler cgi-script 

</Directory> 




















Step 6: Change the user and group of Apache daemon in httpd.conf, and save the 
file: 


User apache 
Group apache 


Step 7: Create the apache user and group: 


adduser apache 


Step 8. Start the Apache web server: 
/www/bin/apachectl start 


Step 9. Unpack and configure TWiki files: 


mkdir /www/htdocs/twiki 

cp /root/TWiki-4.1.2.tgz /www/htdocs/twiki/ 
cd /www/htdocs/twiki 

tar -zxvf TWiki-4.1.2.tgz 

cp ./bin/LocalLib.cfg.txt ./bin/LocalLib.cfg 
chown -R apache:apache /www/htdocs/twiki 





Step 10: Edit TWiki LocalLib.cfg library configuration file: 


cd /www/htdocs/twiki/bin 
vi LocalLib.cfg 
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Step 11: Change the path to lib directory of the TWiki installation and save the 
file: 
StwikiLibPath = “/www/htdocs/twiki/lib” 


Step 12: Configure the TWiki engine by starting a web browser and access the 
TWiki configure script through the following URL: 





http://<server-ip-address>/twiki/bin/configure 
Click “Save” at the bottom of the page to ignore the warning messages under “General 
Path Setting”. At the next prompt, click save again, this will bring to a “Updating 
configuration” page with a summary of the configuration changes. Click ‘Return to 
Configuration”. 


e Under “Security Setups->Authentication->{Login Manager}”’, select “Template 
Login”. 

e Under “Security Setups->Registration-> {Register} {NeedVerification}”, uncheck the 
checkbox. 

e Under “Store Settings->{StoreImpl}, select “RCSLite”. 

e Under “Mail and Proxies->{WebMasterEmail }”, enter 
admin@mlsserver.cisrlabmlistestbedl1.com. 

e Under “Mail and Proxies->{MailPrograml}”, leave the field blank. 

e Click “Next” at the bottom of the page. 

e Select and confirm a password, and click save, and then click “Return to 
configuration” on the next page that appears. 





Step 13: Verify that the installation is working, by clicking on the link “browse to 
the TWiki WebHome” in the configuration page of Step 12. A user should then be able 
to login as TestUserl and browse to the Main WebHome page by clicking on the “Main 
Web” link. A page with the header “Welcome to the Main Web” with the text 
“Congratulations, you have finished the TWiki installation” will be displayed. 


Once all these steps are performed, the installation of Apache and TWiki on 


RedHat Linux has been completed. The tests outlined in Section 2.1 and 2.4 of Appendix 


B should be performed to ensure that the software is working correctly. 
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C. SINGLE LEVEL XTS INSTALLATION 


The procedures outlined in this section are to be performed as the “admin” user on 
the XTS-400 machine running standard STOP configuration. These procedures will copy 
the source code from the wiki installation CD, install and configure the Apache 1.3.34 
web server and the TWiki 4.1.2 wiki engine on the server. In this section, perl v5.8.0 or 
above scripting engine is assumed to be installed on the server. 

In a single level XTS-400 environment, all data coming in and out of the server 
takes on the security level of the network interface card. Therefore, the following 
instructions must be performed under the session level sl1:i13, which is the security level 


configured for the network interface card for the single level prototype. 


Step 1. Copy the Apache web server, the required CPAN modules, and the TWiki 
wiki engine from the MYSEA installation CD: 


(set security and integrity levels — min:oss) 


SAK 

Enter command? run 

cd /home/admin 

cdtool cp /dev/cdrom /apache_1.3.34.tar.gz 

-Japache. 1.3.34 ter: gz 

cdtool cp /dev/cdrom /TWiki-4.1.2.tgz ./TWiki-4.1.2.tgz 

cdtool cp /dev/cdrom /CPAN/perl-Error-0.15- 

2.0.rh8.dag.noarch.rpm ./perl-Error-0.15- 

2.0.rh8.dag.noarch.rpm 

cdtool cp /dev/cdrom /CPAN/perl—-FreezeThaw-0.43 
O.dag.rh80.noarch.rpm ./perl—-FreezeThaw-0.43 
O.dag.rh80.noarch.rpm 

cdtool cp /dev/cdrom /CPAN/perl-Time-modules-—2003.1126- 

1.0.rh9.rf.noarch.rpm ./perl—-Time-modules—2003.1126- 

1.0.rh9.rf.noarch.rpm 

cdtool cp /dev/cdrom /CPAN/perl-DBI-1.40-5.i386.rpm ./perl- 

DBI-1.40-5.1386.rpm 

cdtool cp /dev/cdrom /CPAN/perl-DB_File-1.804-55.i386.rpm 

./perl-DB_File-1.804-55.1386.rpm 

cdtool cp /dev/cdrom /CPAN/perl-CGI-Session-4.00_08- 

1.0.rh9.rf.noarch.rpm ./ perl—-CGI-Session-4.00_08- 

1.0.rh9.rf.noarch.rpm 

cdtool cp /dev/cdrom /CPAN/perl-CGI-2.81-88.3.1386.rpm 
uf PET I-CETS2 . S168. 32 3336.20pm 
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cdtool cp /dev/cdrom /CPAN/libpng10-1.0.13-5.1386.rpm 
./libpng10-1.0.13-5.1386.rpm 
cdtool cp /dev/cdrom /CPAN/gd-1.8.3-4.i386.rpm ./gd-1.8.3- 
4.1386.rpm 
cdtool cp /dev/cdrom /CPAN/perl-GD-1.41-0.rh80.dag.i386.rpm 
./perl-GD-1.41-0.rh80.dag.i386.rpm 
cdtool cp /dev/cdrom /CPAN/perl—-HTML-Tagset—3.10 
1.ch9.rf.noarch.rpm ./perl-HTML-Tagset-—3.10 
1.rh9.rf.noarch.rpm 
cdtool cp /dev/cdrom /CPAN/perl-HTML-Parser-3.55 
1.rh9.rf.i386.rpm ./perl-HTML-Parser-3.55 
1.rh9.rf.i386.rpm 
cdtool cp /dev/cdrom /CPAN/perl-HTML-Tr Ceeaiey) 
O.dag.rh80.noarch.rpm ./perl—-HTML-Tr S27 
O.dag.rh80.noarch.rpm 




































































Step 2. Change the security level of the TWiki and Apache files to s11:113: 








SAK 

Enter command? fsm 
Enter request? change 
Enter pathname? /hnome/admin/TWiki-4.1.2.tgz 
Modify access level? yes 
Enter new security level? sl1 
Enter new integrity level? LS 

Is the level correct? yes 
Enter new owner name? admin 
Enter new group name? stop 
Modify discretionary access? no 
Display the object? no 

Okay to change? yes 


Repeat the above steps for the file: apache_1.3.34.tar.gz, entering the pathname 
/home/admin/apache_1.3.34.tar.gz . 


Step 3. Install the required CPAN modules: 
(set security and integrity levels — min:oss) 


SAK 
Enter command? run 


rem —-ivh perl-Error-0.15-2.0.rh8.dag.noarch.rpm 
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rpm —-ivh perl-FreezeThaw—-0.43-0.dag.rh80.noarch.rpm 

rpm —-ivh perl-Time-modules-—2003.1126-1.0.rh9.rf.noarch.rpm 
rpm -ivh perl-DBI-1.40-5.i386.rpm 

rpm -ivh perl-DB_File-1.804-55.i386.rpm 

rem —ivh perl-CGI-Session-4.00_08-1.0.rh9.rf.noarch.rpm 
rpm —-ivh perl-CGI-2.81-88.3.1386.rpm 

rem -ivh libpng10-1.0.13-5.1386.rpm 

rpm -ivh gd-1.8.3-4.1386.rpm 

rpm -ivh perl-GD-1.41-0.rh80.dag.i386.rpm 

rpm —-ivh perl-HTML-Tagset-—3.10-1.rh9.rf.noarch.rpm 

rem -ivh perl-HTML-Parser-3.55-1.rh9.rf.i386.rpm 

rpm -ivh perl-HTML-Tr 3.17-0.dag.rh80.noarch.rpm 




































































Step 4. Create Apache directory for s11:113: 


(set security and integrity level — min:oss) 





SAK 

Enter command? fsm 

Enter request mkdir 

Enter the directory to create /home/admin/apache 
Should this be a deflection directory No 

[fsm:Main] 

Enter request change 

Enter pathname? /home/admin/apache 
Modify access level? yes 

Enter new security level? sil 

Enter new integrity level? Le 

Is the level correct? Yes 

Modify discretionary access? Yes 

Enter new owner name? admin 

Enter new group name? mysea 

Enter object mode for owner? rwWwx 

Enter object mode for group? rx 

Enter object mode for others? LX 

Display the object? no 

Okay to change? yes 


Step 5. Unpack, build and install the Apache web server: 


(set security and integrity levels — s]1:113) 
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SAK 
Enter command? run 


cd /home/admin/ 

cp apache_1.3.34.tar.gz ./apache 

cd ./apache 

tar -zxvf apache_1.3.34.tar.gz 

cd /home/admin/apache/apache_1.3.34 
./configure --prefix=/home/admin/apache/ 
make 

make install 


Step 6. Save and edit the default Apache configuration: 


cd /home/admin/apache/conf 
cp httpd.conf httpd.conf.bak 
vi httpd.conf 














Step 7. Append the following lines to the “http.conf” file and save the file: 


A 





Directory /home/admin/apache/htdocs/twiki/bin> 
Options ExecCGI FollowSymLinks 
Order allow, deny 
Allow from all 
SetHandler cgi-script 
</Directory> 




















Step 8. Start the Apache web server: 
/home/admin/apache/bin/apachectl start 


Step 9. Unpack and configure TWiki files: 


mkdir /home/admin/apache/htdocs/twiki 

cp /home/admin/TWiki-4.1.2.tgz /home/admin/apache/htdocs/twiki 
cd /home/admin/apache/htdocs/twiki 

tar -zxvf TWiki-4.1.2.tgz 

cp ./bin/LocalLib.cfg.txt ./bin/LocalLib.cfg 








Step 10: Edit TWiki LocalLib.cfg library configuration file: 


cd /home/admin/apache/htdocs/twiki/bin 
vi LocalLib.cfg 
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Step 11: Change the path to lib directory of the TWiki installation and save the 
file: 
StwikiLibPath = “/home/admin/apache/htdocs/twiki/lib” 


Step 12: Create twiki temporary directory: 


cd /tmp 
mkdir twiki 


Step 13: Configure the TWiki engine by starting a web browser and access the 
TWiki configure script through the following URL: 





http://<server-ip-address>/twiki/bin/configure 
Click “Save” at the bottom of the page to ignore the warning messages under “General 
Path Setting”. At the next prompt, click save again, this will bring to a “Updating 
configuration” page with a summary of the configuration changes. Click ‘Return to 
Configuration”. 


e Under “Security Setups->Authentication->{Login Manager}”’, select “Template 
Login’. 

e Under “Security Setups->Registration-> {Register} {NeedVerification}”, uncheck the 
checkbox. 

e Under “Store Settings->{StoreImpl}, select “RCSLite”. 

e Under “Mail and Proxies->{WebMasterEmail }”, enter 
admin@mlsserver.cisrlabmlstestbedl .com. 

e Under “Mail and Proxies->{MailPrograml]}”, leave the field blank. 

e Click “Next” at the bottom of the page. 

e Select and confirm a password, and click save, and then click “Return to 
configuration” on the next page that appears. 





Step 14: Verify that the installation is working, by clicking on the link “browse to 
the TWiki WebHome” in the configuration page of Step 13. A user should then be able 
to login as TestUserl and browse to the Main WebHome page by clicking on the “Main 
Web” link. A page with the header “Welcome to the Main Web” with the text 
“Congratulations, you have finished the TWiki installation” will be displayed. 
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Once all these steps are performed, the installation of Apache and TWiki on the 
single level XTS has been completed. The tests outlined in Section 2.2, 2.5 and 2.7 of 


Appendix B should be performed to ensure that the software is working correctly. 


D. MULTI LEVEL XTS INSTALLATION 


The procedures outlined in this section are to be performed as the “admin” user on 
the XTS-400 machine. These procedures will copy the source code from the wiki 
installation CD, install and configure the TWiki 4.1.2 wiki engine on the server. In this 
section, MYSEA version 2.0, Apache 1.3.34 and perl 5.8.0 or above are assumed to be 


installed. 


Step 1. Copy the TWiki wiki engine and CPAN modules from the installation 


CD: 

(set security and integrity level - min:oss) 
SAK 
Enter command? run 


cd /home/admin 

cedtool cp /dev/cdrom /TWiki-4.1.2-MYSEA.tgz ./TWiki-4.1.2- 

MYSEA.tgz 

cdtool cp /dev/cdrom /CPAN/perl-Error-0.15- 
2.0.rh8.dag.noarch.rpm ./perl-Error-0.15- 
2.0.rh8.dag.noarch.rpm 

cdtool cp /dev/cdrom /CPAN/perl-FreezeThaw-0.43 
O.dag.rh80.noarch.rpm ./perl—-FreezeThaw-0.43 
O.dag.rh80.noarch.rpm 

cdtool cp /dev/cdrom /CPAN/perl-Time-modules-—2003.1126- 

1.0.rh9.rf.noarch.rpm ./perl—-Time-modules—2003.1126- 

1.0.rh9.rf.noarch.rpm 

cdtool cp /dev/cdrom /CPAN/perl-DBI-1.40-5.1386.rpm ./perl- 

DBI-1.40-5.1386.rpm 

cdtool cp /dev/cdrom /CPAN/perl-DB_File-1.804-55.i386.rpm 

./perl-DB_File-1.804-55.1386.rpm 

cdtool cp /dev/cdrom /CPAN/perl-CGI-Session-4.00_08- 

1.0.rh9.rf.noarch.rpm ./ perl—-CGI-Session-4.00_08- 

1.0.rh9.rf.noarch.rpm 
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cdtool 


cdtool 


cdtool 


cdtool 








cdtool 


cdtool 


./libpngl0-1.0.1 


cp /dev/cdrom 
./perl-CGI-2.81 





/CPAN/perl-CGI-2.81-88.3.1386.rpm 











cp /dev/cdrom 





88.3.1386.rpm 


/CPAN/libpng10-1.0.13-5.i386.rpm 








3-5.1386.rpm 





cp /dev/cdrom 
4.1386.rpm 
cp /dev/cdrom 





./perl-GD-1. 4] 





/CPAN/gd-] 


/CPAN/perl 


1.8.3-4.1386.rpm ./gd-1.8.3- 








GD-1.41-0.rh80.dag.1386.rpm 


0.rh80.dag.i386.rpm 








cp /dev/cdrom 





1.rh9.rf.noarch.rpm 
1.rh9.rf.noarch.rpm 
cp /dev/cdrom /CPAN/perl-HTML-Parser-3.55 
1.rh9.rf.i386.rpm ./perl-HTML-Parser-3.55 
1.rh9.rf.i386.rpm 








/CPAN/perl 
./perl-HTML-Tagset-—3.10 











HTML-Tagset—3.10 














cdtool cp /dev/cdrom /CPAN/perl—-HTML-Tr B17 
O.dag.rh80.noarch.rpm 
O.dag.rh80.noarch.rpm 





./perl-HTML-Tr cea 


Step 2. Change the security level of the TWiki files to sl1:110: 


SAK 


Enter command? 

Enter request? 

Enter pathname? 

Modify access level? 

Enter new security level? 
Enter new integrity level? 

Is the level correct? 

Modify discretionary access? 
Display the object? 
Okay to change? 


fsm 


change 
/home/admin/TWiki-4.1.2-MYSEA.tgz 


yes 





no 
yes 





Step 3. Install the required CPAN modules: 


(set security and integrity levels — min:oss) 


SAK 


Enter command? 


run 


rem -ivh perl-Error-0.15-2.0.rh8.dag.noarch.rpm 
rpm —ivh perl-FreezeThaw—-0.43-0.dag.rh80.noarch.rpm 
rpm -ivh perl-Time-modules—-2003.1126-1.0.rh9.rf.noarch.rpm 


rem —-ivh 


























perl-DBI-1.40-5.1386.rpm 


rom -ivh perl-DB_File-1.804-55.1386.rpm 
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rem —ivh perl-CGI-Session-4.00_08-1.0.rh9.rf.noarch.rpm 
rpm —-ivh perl-CGI-2.81-88.3.1386.rpm 

rem -ivh libpngl10-1.0.13-5.1386.rpm 

rpm -ivh gd-1.8.3-4.1386.rpm 

rem —ivh GD-1.41-0.rh80.dag.1386.rpm 

rpm —ivh 1-HTML-Tagset—3.10-1.rh9.rf.noarch.rpm 

rpm —ivh 1-HTML-Parser-3.55-1.rh9.rf.1i386.rpm 

rpm —ivh 1-HTML-Tr 3.17-0.dag.rh80.noarch.rpm 















































KKH KH 








Oo T'0 OT CO 


Step 4. Skip to Step 8 if WebDAV if is not installed on the server. Edit the 
Apache install configuration: 


(set security and integrity level — s10:113) 


cd /usr/local/mysea/apache/sre 


vi Configuration 


Step 5. Comment out the following text at the end of the “Configuration” file to 
remove the WebDAV module: 
# AddModule modules/dav/libdav.a 


Step 6: Build Apache: 
./Configure 


make 


Step 7: Replace Apache httpd binary file: 


cd /usr/local/mysea/bin 
mv httpd httpd_webdav 
cp /usr/local/mysea/apache/src/httpd ./ 














Step 8. Save and edit the default Apache configuration: 


(set security and integrity level — s10:113) 


SAK 
Enter command? run 
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cd /home/http/conf 
cp httpd.conf httpd.conf.bak 
vi httpd.conf 














Step 9. Append the following lines to the “http.conf” file: 


A 


Directory /home/http/htdocs/twiki/bin> 
Options ExecCGI FollowSymLinks 
Order allow,deny 
Allow from all 
SetHandler cgi-script 

</Directory> 




















Step 10 : Skip to Step 11 if WebDAV is not installed on the server. Comment out 


the following text from the “httpd.conf” file: 











# DAVLockDB /usr/local/apachel3/var/DAVLock 
# <Location /dav> 

+ DAV on 

# </Location> 





Step 11: Skip to Step 12 if WebShell is not installed on the server. Delete the 
WebShell cgi script: 


cd /home/http/cgi-bin 
rm WebShell.cgi 


Step 12. Create a twiki directory for s11:110 to unpack and configure TWiki files: 


(set security and integrity level — s10:113) 


SAK 

Enter command? fsm 

Enter request mkdir 

Enter the directory to create /home/http/htdocs/twiki 
Should this be a deflection directory No 

[fsm:Main] 

Enter request change 

Enter pathname? /home/http/htdocs/twiki 
Modify access level? yes 

Enter new security level? sll 
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Enter new integrity level? 11:0 


Is the level correct? Yes 
Modify discretionary access? Yes 
Enter new owner name? admin 
Enter new group name? other 
Enter object mode for owner? wx 
Enter object mode for group? wx 
Enter object mode for others? rx 
Display the object? no 
Okay to change? yes 


(set security and integrity level — s11:110) 


SAK 
Enter command? run 


cp /home/admin/TWiki-4.1.2-MYSEA.tgz /home/http/htdocs/twiki 
cd /home/http/htdocs/twiki 

tar -zxvf TWiki-4.1.2-MYSEA.tgz 

orc manne 
chown -R admin:other /home/http/htdocs/twiki 











Step 13: Rename default Trash directory: 


cd /home/http/htdocs/twiki/data 


mv Trash Trash_org 


Step 14: Re-create Trash directory as deflection directory: 
(set security and integrity level — s11:110) 


SAK 

Enter command? fsm 

Enter request? mkdir 

Enter pathname? /home/http/htdocs/twiki/data/Trash 
Is it a deflection dir? yes 

Enter directory mode for owner? rwx 

Enter directory mode for group? rwXx 

Enter directory mode for others? Lx 
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Step 15: Create content directory at the SIM_UNCLASSIFIED security level: 
(set security and integrity level — sl1:110) 


SAK 
Enter command? fsm 
Enter request mkdir 


Enter the directory to create 
/home/http/htdocs/twiki/data/SIM_UNCLASSIFIED 









































Should this be a deflection directory No 
[fsm:Main] 
Enter request change 
Enter pathname? 
/home/http/htdocs/twiki/data/SIM_UNCLASSIFIED 
Modify access level? yes 
Enter new security level? sit 
Enter new integrity level? i10 
Is the level correct? Yes 
Modify discretionary access? Yes 
Enter new owner name? admin 
Enter new group name? other 
Enter object mode for owner? wx 
Enter object mode for group? wx 
Enter object mode for others? rap 
Display the object? no 
Okay to change? yes 
[fsm:Main] 
Enter request mkdir 


Enter the directory to create 









































/home/http/htdocs/twiki/pub/SIM_UNCLASSIFIED 

Should this be a deflection directory No 

[fsm:Main] 

Enter request change 

Enter pathname? 
/home/http/htdocs/twiki/pub/SIM_UNCLASSIFIED 

Modify access level? yes 

Enter new security level? sit 

Enter new integrity level? i10 

Is the level correct? Yes 

Modify discretionary access? Yes 

Enter new owner name? admin 

Enter new group name? other 

Enter object mode for owner? rwWwx 

Enter object mode for group? rwWwx 


Enter object mode for others? rx 
Display the object? no 
Okay to change? yes 


Step 16: Populate content directory at the SIM_UNCLASSIFIED security level: 
(set security and integrity level — s11:110) 


SAK 
Enter command? run 

















cd /home/http/htdocs/twiki/data/SIM_UNCLASSIFIED 
cp -r /home/http/htdocs/twiki/data_testing/SIM_UNCLASS 
COs 
cp -r /home/http/htdocs/twiki/data_testing/Main/ ./ 
chown —-R admin:other SIM _UNCLASS ED 

chown -R admin:other Main 
cd /home/http/htdocs/twiki/pub/SIM_UNCLASSIFIED 
cp -r /home/http/htdocs/twiki/pub_testing/SIM_UNCLASSIFIED/* 
cd 
chown -R admin:other SIM_UNCLASS 























iD/* 





ny 
ty 






































| 






























































| 





ED 








Step 17: Populate Trash directory at each security level: 


(set security and integrity level — s11:110) 


cd /home/http/htdocs/twiki/data 
chmod 775 Trash 

cd Trash 

cp ../Trash_org/* ./ 

chmod 664 * 

CO! ats 

chown —-R admin:other Trash 


Step 18: Create twiki temporary directory at the SIM_UNCLASSIFIED security 
level: 
(set security and integrity level — s11:110) 


cd /tmp 

mkdir twiki 

chmod 775 twiki 

chown admin:other twiki 


75 


Repeat the Step 15 to 18 for the following classification level while logged in at 
the appropriate security and integrity level: 


SIM_SECRET sI5 (scl) : i10 


Step 19: Restore files to be used for testing from tape: 
(set security and integrity level — max:max) 


SAK 
Enter command? frestore 
/dev/tapel for input source 
<CR> for volume name 
(when instructed, load tape, write protected ‘slide 
open’ ) 
restore for enter request 
n for replace newer objects with older 
n for display pathnames 
n for restore access and modify times 
y for restore owner/group of restored objects 
<CR> for relative pathname selection 
<CR> for destination pathname (default should be 
“/home/http/htdocs/twiki/data” 
Exit for Enter request 
(remove tape from tape drive after it is ejected) 


























Step 20: Copy the SIM_UNCLASSIFIED directory under the pub directory 
restored in Step 19 to /home/http/htdocs/twiki/pub: 


(set security and integrity level — s11:110) 





cp -rp /home/http/htdocs/twiki/data/pub/SIM_UNCLASS 
/home/http/htdocs/twiki/pub 








Hy 
[7] 
io) 











Step 21: Login to the XTS server through TPE or TCBE at the 
SIM_UNCLASSIFIED level (sl1:110). Configure the TWiki engine by starting a web 
browser and access the TWiki configure script through the following URL: 





http://<server-ip-address>/twiki/bin/configure 


e Under “Security Setups->Authentication->{Login Manager}”’, select “Template 
Login’. 

e Under “Security Setups->Registration-> {Register} {NeedVerification}”, uncheck the 
checkbox. 

e Under “Store Settings->{StoreImpl}’, select “RCSLite”’. 
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e Under “Store Settings->{RCS } {dirPermission}”, enter “0775” 

e Under “Store Settings->{RCS } {filePermission }’’, enter “0664” 

e Under “Mail and Proxies->{WebMasterEmail }”, enter 
admin@mlsserver.cisrlabmlstestbedl .com. 

e Under “Mail and Proxies->{MailPrograml]}”, leave the field blank. 

e Click “Next” at the bottom of the page. 

e Key in “password” as the password, and click save, and then click “Return to 
configuration” on the next page that appears. 





Step 22: Verify that the installation is working, by clicking on the link “browse to 
the TWiki WebHome” in the configuration page. A user should then be able to login as 
TestUserl and browse to the Main WebHome page by clicking on the “Main Web” link. 
A page with the header “Welcome to the Main Web” with the text “Congratulations, you 
have finished the TWiki installation” will be displayed. 


Once all these steps are performed, the installation of Apache and TWiki on the 


multi level XTS has been completed. The tests outlined in Section 2.3, 2.6 and 2.8 of 


Appendix B should be performed to ensure that the software is working correctly. 


a 


THIS PAGE INTENTIONALLY LEFT BLANK 
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APPENDIX B: TEST PROCEDURES 


A. DESCRIPTION 


This TWiki Test Procedure is intended to implement the TWiki Test Plan. This 
procedure will provide details on testing covered for acceptance of TWiki integration into 
MYSEA Testbed. 


B. TEST DETAILS 


1. Test Setups 


TWiki Test setup includes the two XTS servers, a Windows clients with Internet 
Explorer 6.0 browser and a Linux client with FireFox 2.0 browser 


Two STOP user accounts are used: mdemo/ and mdemo2. 

Three TWiki user accounts are used: AdminUser, TestUserl and TestUser2. 

The mdemol user holds the TestUser] TWiki account and the AdminUser TWiki 
account, and the mdemo2 user holds the TestUser2 TWiki account. 


The following tables show the TWiki DAC and OS MAC setting of the test webs and 
topics. (legend: AU: AdminUser, TU1: TestUser1, TU1,2: TestUserl & TestUser2, 

AT: AllowTopic, DT: DenyTopic, AW: AllowWeb, DW: DenyWeb, N.A.: not 
applicable, a dash ‘*-“ : not set) 
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Twiki DAC OS MAC 

TWiki Web Twiki Topic JAW [Dw [AT [DT [AW [DW [AT |DT_ [AW |DW_|AT__[DT___|only) 
restrumciona ust | sib motive) 
Test_Functional List ee ee a ae ee a multilevel) 
restrunionat epi | EE sibio muti) 
Test_Functional Display1 ae ee a multilevel) 
restrunionat —_—ospiga |; | t sibio mute) 
Test_Functional Display2 a ee ee ee multilevel) 
rest Fucionas ___—_foowmoas |. FFL bo ote) 
Test_Functional Download a a multilevel) 
restfuntona fet; [oto atin 
Test_Functional dit1 sl0:il0 (multilevel) 
restrumtons fae si0i0 (mute) 
Test_Functional dit2 a ae ae a multilevel) 
restrumciona ete § od; EEE sib ote) 
Test_Functional reate a a a a multilevel) 
estrumciona fee | |; feo atin 
Test_Functional elete sl0:il0 (multilevel) 
rest runionat poet sibio mute) 
Test_Functional pload a a a multilevel) 
est runtonat ____(mutancowses | |; oso tine 
Test_Functional imultaneousEdit sl0:il0 (multilevel) 
rest uncionai ___—_feermsson |---| sib motive) 
Test_Functional etPermission ae a ae ee ee multilevel) 
rest unionat ____conigue |; | ff}. sibso muti) 
Test_Functional Configure ae a a ea ae multilevel) 
rest runtonat __—_egteser |; | ff} sioi0 (mative) 
Test_Functional RegisterUser aa a ae ee a multilevel) 


Table 23. Functional Test Permission Settings 
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Twiki DAC OS MAC 
(Obj Label, for XTS 
TWiki Web Twiki Topic JAW [DW |AT [DT JAW |DW_ IAT [DT [AW |DW_ [AT [DT __ only) 


FTest DAC _LinuxBL1[TestTopic | |- |tur jrur |} |} | |} | | NAS 
FTest DAC_Linux/BL2___[TestTopic____|-__ [rua frur |} | |} |} INAS 
es DACUnUWBLS ——— Iiesopie = — Ue ee af (Mee ee IN 
FTest_ DAC_Linux/BL4___[TestTopic [|---| - - |_|} _,fur jr |} INAS 
FTest DAC_LinuxBL5___[TestTopic [|__| [Tura |ruae | fmiep NA OCSC~SCS 
FTest_ DAC _Linux/BL6_[TestTopic | |» Tura. >) _|rur2)- > |} [rua INAS 
FTest_ DAC_Linux/BL7 ___[TestTopic [|__| _|Tur2|- |} |} [ruiz] |} [rua INA SCS 
FTest_ DAC_SingleLevelBS1 [TestTopic |__| _|tur [ru |} | | | | ste SSCS 
FTest_ DAC SingleLeveVBS2_[TestTopic ___|-__[rua_frur |---| |---| stig 
FTest_ DAC_SingleLeveV/BS3 _[TestTopic [|---| (mi | [| |---| | — - _|sia SSCS 
FTest_ DAC SingleLevelBS4 [TestTopic |---| |---| ror _frur_ | _} _fsitia SSC 
FTest_ DAC SingleLeveVBS5_[TestTopic ___|-__[-__|Tur2|-__- i 

FTest_ DAC _SingleLevel/BS6_[TestTopic |__| |Tut2|- > _ 
FTest_ DAC_MultiLevelBMi [TestTopic |__| |Tur_|rur 
FTest_ DAC MultiLevelBM2_[TestTopic ____|-__[Tui_|Tur_ |_| __ 
FTest_ DAC_MultiLevel/BM3_[TestTopic eee ea ea SE 
FTest_DAC_MultiLevel/BM4 [TestTopic Pees | en Cae oe 
FTest_ DAC_MultiLevelBM5[TestTopic |__| |Tur2|-_(- 
FTest_ DAC MultiLevelBM6 [TestTopic | _- _|Tur2|- > 


Table 24. DAC Test Permission Settings. 


SIM_UNCLASSIFIED 
SIM_UNCLASSIFIED 
SIM_UNCLASSIFIED 
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Twiki DAC OS MAC 
(Obj Label, for XTS 
TWiki Web Twiki Topic JAW |DW IAT |DT_ |AW [DW [AT [DT [AW [DW [AT [DT ___|only) 


[Test MAC_SingleLevel/CS1 [Testfopic fe /  TU e sizig 
[Test_MAC_SingleLevel/CS2 [TestTopic fe FU sig 
[Test_MAC_SingleLevel/CS3 [TestTopic fe TUT siti 
[Test_MAC_SingleLevel/CS4 [TestTopic [> f- TUT eT sis 
[Test_MAC_SingleLevel/CS5 [Testfopic [> TU eT sig 
[Test_MAC_SingleLevel/CS6 [TestTopic 0 [- @ TUT siti 
[Test MAC_MultiLeve/CM1_[TestTopic [>> TUT ee SIM_SECRET __ 
[Test_MAC_MultiLevel/CM2_|Testlopic |---| EU -SIM_UNCLASSIFIED | 
[Test MAC_MultiLeve/CM3_[TestTopic [> ? TUT SIM_UNCLASSIFIED_| 
[Test MAC_MultiLevel/CM4_[TestTopic f/f} SIMUSECRET 
[Test MAC_MultiLeve/CM5 [TestTopic [> f> TUT FT TU -SIM_UNCLASSIFIED_| 
[Test MAC_MultiLeve/CM6__[Testfopic [> TU EU SIM_UNCLASSIFIED_| 
[Test MAC_MultiLeve/CM7_[TestTopic [> FTA EU SIM_UNCLASSIFIED_| 
Test_Integration _—sfTestfopic > SIM_UNCLASSIFIED_| 


Table 25. MAC Test and Integration Test Permission Settings. 
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2. Test Procedures 


2.1. Functional Tests (Linux) 


These tests verify that all TWiki functionalities are behaving correctly. 


2.1.1. List Wiki Web/Pages Test Instruction (A1) 


In a new browser window, connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A1FunctionalTestList’. 

Expecting a listing of Functional Test wiki pages Al to A11. 

Close the browser window. 

Repeat the above steps using a second client and login to TWiki as TestUser2. 
Expecting a listing of Functional Test wiki pages Al to All 

Close the browser window. 

. Annotate completion by initialing box to the left. 


2.1.2. Display Wiki Pages Test Instruction (A2) 


In a new browser window, connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A2FunctionalTestDisplay1”. 

Expecting a display of the content of the wiki page: “This is Display Test 1”. 
Close the browser window. 

Repeat the steps 1 to 3 using a second client and login to TWiki as TestUser2. 
Click on wiki page: “A2FunctionalTestDisplay2”. 

Expecting a display of the content of the wiki page: “This is Display Test 2”. 
. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.1.3. Download File Test Instruction (A3) 


. In anew browser window, connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
. Login to TWiki as TestUser1. 

. Browse to Test_Functional directory using sidebar 
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Click on wiki page: “A3FunctionalTestDownload”’. 

Download a file: right click on the file 
“Functional_Test_Download_File1.txt”, select “save target as”. 
Expecting the file to be downloaded into client’s selected directory. 
Close the browser window. 


Repeat the step | to 4 using a second client and login to TWiki as TestUser2. 


Download a file: right click on the file 
“Functional_Test_Download_File2.txt”, select “save target as”. 


. Expecting the file to be downloaded into client’s selected directory. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.1.4. Edit Wiki Page Test Instruction (A4) 


In a new browser window connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A4FunctionalTestEdit!”. 

Edit the A4FunctionalTestEdit! page: click “Edit”. 

Modify the wiki page and save the modified wiki page. 

Expecting successful modification and display of the modified content. 
Modify the wiki page to its original state and save. 

Close the browser window. 


. Repeat steps 1to 3 using a second client and login to TWiki as TestUser2. 
. Click on wiki page: “A4FunctionalTestEdit2”. 

. Edit the A4FunctionalTestEdit2 page: click “Edit”.. 

. Modify the wiki page and save the modified wiki page. 

. Expecting successful modification and display of the modified content. 

. Modify the wiki page to its original state and save. 

. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.1.5. Create new Wiki Page Test Instruction (A5) 


In a new browser window connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A5FunctionalTestCreate”’. 

Edit the A5FunctionalTestCreate page: click “Edit”. 

Create a link to a new page: type “[[new page1]]” in the edit box. 
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Save the modified wiki page. 
Click on the “*?” link beside the “new pagel” text on the displayed content. 
Type in some text and save the wiki page. 


. Expecting successful modification and display of the modified content. 
. Close the browser window. 
. Repeat the steps 1 to 9 using a second client and login to TWiki as TestUser2, and 


creating the new page as [[new page2]]. 


. Expecting successful modification and display of the modified content. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.1.6. Delete Authorized file Test Instruction (A6) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory. 

Click on “index”, and then click the “NewPage1” topic created in the Create test 
case. 

Click on “More topic actions” on the lower right corner. 

Click “Delete topic..., looking for references in all public webs (recommended)” 
option. 

Click “Delete” in the next screen. 

Expecting successful deletion and display of “new page1?” showing the page 
does not exist. 

Close the browser window. 


. Repeat steps 1 to 7 using a second client and login to TWiki as TestUser2, and 


deleting the “new page2” page. 


. Expecting successful deletion and display of “new page2?” showing the page 


does not exist. 
Close the browser window. 
Annotate completion by initialing box to the left. 


2.1.7. Upload Authorized File(s) Test Instruction (A7) 


In a new browser window connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A7FunctionalTestUpload”. 

Create 3 files on client’s current directory with distinct filenames. 

Upload first file to A7FunctionalTestUpload page: click on “Attach”, and select 
the first file using “browse”, then click “upload file”. 
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. Expecting first file uploaded. 
. Upload second and third files. 


Expecting both files uploaded. 


. Close the browser window. 

. Repeat steps | to 8 using a second client and login to TWiki as TestUser2. 

. Expecting all three files uploaded. 

. Close the browser window. 

. On Linux Server, login as root and verify 
/home/http/htdocs/twiki/pub/Test_Functional/A7FunctionalTestUpload/ directory 


contains those six files. 
Close the browser window. 
Annotate completion by initialing box to the left. 


2.1.8. Simultaneous Edit File Test Instruction (A8) 


In a new browser window connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A8FunctionalTestSimultaneousEdit”. 

Edit the wiki page: click “Edit”, and type in “edited by TestUser1”. 

In new browser window on another client machine connect to TWiki on Linux 
server. Type: “http://192.168.0.200/twiki/bin/view/Main/WebHome” as the 
URL. 

Login to TWiki as TestUser2. 

Browse to Test_Functional directory. 

Edit the same “A8FunctionalTestSimultaneousEdit” wiki page. 


. Expecting a warning message saying TestUser1 is editing the file. 

. Click “Edit anyway” to ignore the warning and continue to edit the file. 

. Edit the wiki page: type in “edited by TestUser2”. 

. On the TestUser1 client, click save. 

. Expecting the content to be save successfully. 

. On the TestUser?2 client, click save. 

. Expecting a warning message on TestUser2 client saying topic was merged. 
. Click “OK” on TestUser2 client. 

. Expecting the display of the difference of the 2 separate edits. 

. Close the two browser windows. 


Annotate completion by initialing box to the left. 


2.1.9. Setting of Permission on File(s) Test Instruction (A9) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
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Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 
Click on wiki page: “A9FunctionalTestSetPermission”. 
Edit the wiki page: click “Edit”. 

Restrict viewing of the page by TestUser1: type “ * Set DENYTOPICVIEW = 
%MAINWEB%.TestUser2” (without quote, must have at least six space before 
*), 

Save the changes. 

Browse to WebHome of Main page. 

Logout of TestUserl and login as TestUser2. 


. Click on wiki page: “A9FunctionalTestSetPermission”. 
. Expecting that access to be denied. 

. Logout of TestUser2 and login as TestUser1, and restore the original permission. 
. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.1.10. Changing TWiki Configuration Test Instruction (A10) 


In a new browser window connect to TWiki on Linux server. Type: 
“http://192.168.0.200/twiki/bin/configure” as the URL. 

Change the following setting: Statistics->{ Stats }{TopViews} to 20 (default = 
10)”. 

Click “Next”. 

Type in “password” and click “Save”. 

Expecting a “Updating Configuration: setting 1 configuration item” message. 
Click “return to configuration’. 

Change the setting back to the original value and save the configuration again. 
Close the browser window. 

Annotate completion by initialing box to the left. 


2.1.11. Register New User Test Instruction (A11) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
Click “Register” on sidebar. 
In the Registration page, key in the following: 
First Name: Test 
Last Name: User3 
Email Address: testuser3 @mlsserver.cisrlabmlstestbed1.com 
Your Password: password 
Retype password: password 
f. Country: USA 
Click “submit”. 
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Expecting successful registration with a “Thank you for registering” message. 
Close the browser window. 
Annotate completion by initialing box to the left. 


2.2. Functional Tests (Single Level XTS with NIC configured at sl1:i13) 


These tests verify that all functionalities provided by adding TWiki into single 


level XTS server are behaving correctly. 
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2.2.1. List Wiki Web/Pages Test Instruction (A1) 


In a new browser window, connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A1FunctionalTestList’. 

Expecting a listing of Functional Test wiki pages Al to All. 

Close the browser window. 

Repeat the above steps using a second client and login to TWiki as TestUser2. 
Expecting a listing of Functional Test wiki pages Al to All. 

Close the browser window. 


. Annotate completion by initialing box to the left. 


2.2.2. Display Wiki Pages Test Instruction (A2) 


In a new browser window, connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A2FunctionalTestDisplay1”. 

Expecting a display of the content of the wiki page: “This is Display Test 1”. 
Close the browser window. 

Repeat the steps 1 to 3 using a second client and login to TWiki as TestUser2. 
Click on wiki page: “A2FunctionalTestDisplay2”. 

Expecting a display of the content of the wiki page: “This is Display Test 2”. 
Close the browser window. 

Annotate completion by initialing box to the left. 
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2.2.3. Download File Test Instruction (A3) 


1. In anew browser window, connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

2. Login to TWiki as TestUser1. 

3. Browse to Test_Functional directory using sidebar 

4. Click on wiki page: “A3FunctionalTestDownload”. 

5. Download a file: right click on the file 
“Functional_Test_Download_File1.txt”, select “save target as”. 

6. Expecting the file to be downloaded into client’s selected directory. 

7. Close the browser window. 

8. Repeat the step 1 to 4 using a second client and login to TWiki as TestUser2. 

9. Download a file: right click on the file 
“Functional_Test_Download_File2.txt”, select “save target as”. 

10. Expecting the file to be downloaded into client’s selected directory. 

11. Close the browser window. 

12. Annotate completion by initialing box to the left. 


2.2.4. Edit Wiki Page Test Instruction (A4) 


1. In anew browser window connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

2. Login to TWiki as TestUser1. 

3. Browse to Test_Functional directory using sidebar. 

4. Click on wiki page: “A4FunctionalTestEdit1”. 

5. Edit the A4FunctionalTestEditl page: click “Edit”.. 

6. Modify the wiki page and save the modified wiki page. 

7. Expecting successful modification and display of the modified content. 

8. Modify the wiki page to its original state and save. 

9. Close the browser window. 

10. Repeat steps 1to 3 using a second client and login to TWiki as TestUser2. 

11. Click on wiki page: “A4FunctionalTestEdit2”. 

12. Edit the A4FunctionalTestEdit2 page: click “Edit”.. 

13. Modify the wiki page and save the modified wiki page. 

14. Expecting successful modification and display of the modified content. 

15. Modify the wiki page to its original state and save. 

16. Close the browser window. 

17. Annotate completion by initialing box to the left. 


2.2.5. Create new Wiki Page Test Instruction (A5) 


1. In anew browser window connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 
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Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A5FunctionalTestCreate”’. 

Edit the A5FunctionalTestCreate page: click “Edit”.. 

Create a link to a new page: type “[[new page1]]” in the edit box. 

Save the modified wiki page. 

Click on the “?” link beside the “new pagel” text on the displayed content. 
Type in some text and save the wiki page. 


. Expecting successful modification and display of the modified content. 
. Close the browser window. 
. Repeat the steps 1 to 9 using a second client and login to TWiki as TestUser2, and 


creating the new page as [[new page2]]. 


. Expecting successful modification and display of the modified content. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.2.6. Delete Authorized file Test Instruction (A6) 


. Inanew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory. 

Click on “index”, and then click the “NewPage1” topic created in the Create test 
case. 

Click on “More topic actions” on the lower right corner. 

Click “Delete topic..., looking for references in all public webs (recommended)” 
option. 

Click “Delete” in the next screen. 

Expecting successful deletion and display of “new pagel?” showing the page 
does not exist. 

Close the browser window. 


. Repeat steps | to 7 using a second client and login to TWiki as TestUser2, and 


deleting the “new page2” page. 


. Expecting successful deletion and display of “new page2?” showing the page 


does not exist. 


. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.2.7. Upload Authorized File(s) Test Instruction (A7) 


. In anew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 
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Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A7FunctionalTestUpload”. 

Create 3 files on client’s current directory with distinct filenames. 

Upload first file to A7FunctionalTestUpload page: click on “Attach”, and select 
the first file using “browse”, then click “upload file”. 

Expecting first file uploaded. 


. Upload second and third files. 


Expecting both files uploaded. 


. Close the browser window. 

. Repeat steps | to 8 using a second client and login to TWiki as TestUser2. 
. Expecting all three files uploaded. 

. Close the browser window. 

. On Single level XTS Server, login as root and verify 


/home/http/htdocs/twiki/pub/Test_Functional/A7FunctionalTestUpload/ directory 
contains those six files. 


. Annotate completion by initialing box to the left. 


2.2.8. Simultaneous Edit File Test Instruction (A8) 


In a new browser window connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A8FunctionalTestSimultaneousEdit”. 

Edit the wiki page: click “Edit”, and type in “edited by TestUser1”. 

In new browser window on another client machine connect to TWiki on Single 
level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser2. 


. Browse to Test_Functional directory. 


Edit the same “A8FunctionalTestSimultaneousEdit” wiki page. 


. Expecting a warning message saying TestUser1 is editing the file. 

. Click “Edit anyway” to ignore the warning and continue to edit the file. 
. Edit the wiki page: type in “edited by TestUser2”. 

. On the TestUser1 client, click save. 

. Expecting the content to be save successfully. 

. On the TestUser?2 client, click save. 

. Expecting a warning message on TestUser2 client saying topic was merged. 
. Click “OK” on TestUser2 client. 

. Expecting the display of the difference of the 2 separate edits. 

. Close the two browser windows. 

. Annotate completion by initialing box to the left. 
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2.2.9. Setting of Permission on File(s) Test Instruction (A9) 


In a new browser window connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A9FunctionalTestSetPermission”. 

Edit the wiki page: click “Edit”. 

Restrict viewing of the page by TestUser1: type “ * Set DENYTOPICVIEW = 
%MAINWEB%.TestUser2” (without quote, must have at least six space before 
**), 


Save the changes. 


. Browse to WebHome of Main page. 


Logout of TestUser1 and login as TestUser2. 


. Click on wiki page: “A9FunctionalTestSetPermission”. 

. Expecting that access to be denied. 

. Logout of TestUser2 and login as TestUser1, and restore the original permission. 
. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.2.10. Changing TWiki Configuration Test Instruction (A10) 


. Inanew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/configure” as the URL. 

Change the following setting: Statistics->{ Stats }{TopViews} to 20 (default = 
10)”. 

Click “Next”. 

Type in “password” and click “Save”. 

Expecting a “Updating Configuration: setting 1 configuration item” message. 

Click “return to configuration’. 

Change the setting back to the original value and save the configuration again. 
Close the browser window. 

Annotate completion by initialing box to the left. 


2.2.11. Register New User Test Instruction (A11) 


. In anew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 
Click “Register” on sidebar. 
In the Registration page, key in the following: 

g. First Name: Test 

h. Last Name: User3 

i. Email Address: testuser3 @mlsserver.cisrlabmlstestbed1.com 
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j. Your Password: password 
k. Retype password: password 
1. Country: USA 
Click “submit”. 
Expecting successful registration with a “Thank you for registering” message. 
Close the browser window. 
Annotate completion by initialing box to the left. 


2.3. Functional Tests (Multilevel XTS) 


These tests verify that all functionalities provided by adding TWiki into MYSEA 


Testbed are behaving correctly. 


SSeS 


2.3.1. List Wiki Web/Pages Test Instruction (A1) 


. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 


the client machine. 

In a new browser window, connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A1FunctionalTestList’. 

Expecting a listing of Functional Test wiki pages Al to All. 

Close the browser window. 

Repeat steps | to 5 using a second client, login to XTS as mdemo2 and login to 
TWiki as TestUser2. 

Expecting a listing of Functional Test wiki pages Al to All. 


. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.3.2. Display Wiki Pages Test Instruction (A2) 


. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 


the client machine. 

In a new browser window, connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A2FunctionalTestDisplay1”. 

Expecting a display of the content of the wiki page: “This is Display Test 1”. 
Close the browser window. 


93 


8. Repeat steps 1 to 4 using a second client, login to XTS as mdemo2?, and login to 
TWiki as TestUser2. 

9. Click on wiki page: “A2FunctionalTestDisplay2”. 

10. Expecting a display of the content of the wiki page: “This is Display Test 2”. 

11. Close the browser window. 

12. Annotate completion by initialing box to the left. 


2.3.3. Download File Test Instruction (A3) 


1. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 
the client machine. 

2. In anew browser window, connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

3. Login to TWiki as TestUser1. 

4. Browse to Test_Functional directory using sidebar 

5. Click on wiki page: “A3FunctionalTestDownload”. 

6. Download a file: right click on the file 
“Functional_Test_Download_File1.txt”, select “save target as”. 

7. Expecting the file to be downloaded into client’s selected directory. 

8. Close the browser window. 

9. Repeat steps | to 5 using a second client, login to XTS as mdemo2, and login to 
TWiki as TestUser2. 

10. Download a file: right click on the file 
“Functional_Test_Download_File2.txt”, select “save target as”. 

11. Expecting the file to be downloaded into client’s selected directory. 

12. Close the browser window. 

13. Annotate completion by initialing box to the left. 


2.3.4. Edit Wiki Page Test Instruction (A4) 


1. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 
the client machine. 

2. In anew browser window connect to TWiki on multilevel XTS server. Type: 

“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A4FunctionalTestEdit!”. 

Edit the A4FunctionalTestEdit1 page: click “Edit”.. 

Modify the wiki page and save the modified wiki page. 

Expecting successful modification and display of the modified content. 

Modify the wiki page to its original state and save. 

0. Close the browser window. 


See ee 
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. Repeat steps Ito 4 using a second client, login to XTS as mdemo2, and login to 


TWiki as TestUser2. 


. Click on wiki page: “A4FunctionalTestEdit2”. 

. Edit the A4FunctionalTestEdit2 page: click “Edit”. 

. Modify the wiki page and save the modified wiki page. 

. Expecting successful modification and display of the modified content. 
. Modify the wiki page to its original state and save. 

. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.3.5. Create new Wiki Page Test Instruction (A5) 


. Establish a SIM_UNCLASSIFIED session for mdemol1 user using the TCBE, for 


the client machine. 

In a new browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A5FunctionalTestCreate”’. 

Edit the A5FunctionalTestCreate page: click “Edit”. 

Create a link to a new page: type “[[new page1]]” in the edit box. 

Save the modified wiki page. 

Click on the “?” link beside the “new pagel” text on the displayed content. 


. Type in some text and save the wiki page. 

. Expecting successful modification and display of the modified content. 

. Close the browser window. 

. Repeat the steps 1 to 10 using a second client, login to XTS as mdemo2?, and login 


to TWiki as TestUser2, and creating the new page as [[new page2]]. 


. Expecting successful modification and display of the modified content. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.3.6. Delete Authorized file Test Instruction (A6) 


. Establish a SIM_UNCLASSIFIED session for mdemol! user using the TCBE, for 


the client machine. 

In a new browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory. 

Click on “index”, and then click the “NewPage1” topic created in the Create test 
case. 

Click on “More topic actions” on the lower right corner. 
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. Click “Delete topic..., looking for references in all public webs (recommended)” 


option. 

Click “Delete” in the next screen. 

Expecting successful deletion and display of “new page1?” showing the page 
does not exist. 


. Close the browser window. 
. Repeat steps 1 to 8 using a second client, login to XTS as mdemo2, and login to 


TWiki as TestUser2, and deleting the “new page2” page. 


. Expecting successful deletion and display of “new page2?” showing the page 


does not exist. 


. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.3.7. Upload Authorized File(s) Test Instruction (A7) 


Establish a SIM_UNCLASSIFIED session for mdemol user using the TCBE, for 
the client machine. 

In a new browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A7FunctionalTestUpload”’. 

Create 3 files on client’s current directory with distinct filenames. 

Upload first file to A7FunctionalTestUpload page: click on “Attach”, and select 
the first file using “browse”, then click “upload file”. 

Expecting first file uploaded. 

Upload second and third files. 


. Expecting both files uploaded. 
. Close the browser window 
. Repeat steps 1 to 9 using a second client, login to XTS as mdemo2, and login to 


TWiki as TestUser2. 


. Expecting all three files uploaded. 
. Close the browser window. 
. On Multilevel XTS Server, login as admin at (s11:i10) and verify 


/home/http/htdocs/twiki/pub/SIM_UNCLASSIFIED/Test_Functional/A7Function 
alTestUpload/ directory contains those six files. 


. Annotate completion by initialing box to the left. 


2.3.8. Simultaneous Edit File Test Instruction (A8) 


. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 


the client machine. 
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In a new browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A8FunctionalTestSimultaneousEdit”. 

Edit the wiki page: click “Edit”, and type in “edited by TestUser1”. 
Establish a SIM_UNCLASSIFIED session for mdemo2 user using the TCBE, for 
another client machine. 

In new browser window on the new client machine connect to TWiki on 
Multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser2. 


. Browse to Test_Functional directory. 

. Edit the same “A8FunctionalTestSimultaneousEdit” wiki page. 

. Expecting a warning message saying TestUser1 is editing the file. 

. Click “Edit anyway” to ignore the warning and continue to edit the file. 
. Edit the wiki page: type in “edited by TestUser2”. 

. On the TestUser1 client, click save. 

. Expecting the content to be save successfully. 

. On the TestUser2 client, click save. 

. Expecting a warning message on TestUser2 client saying topic was merged. 
. Click “OK” on TestUser2 client. 

. Expecting the display of the difference of the 2 separate edits. 

. Close the two browser windows. 

. Annotate completion by initialing box to the left. 


2.3.9. Setting of Permission on File(s) Test Instruction (A9) 


. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 


the client machine. 

In a new browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Browse to Test_Functional directory using sidebar. 

Click on wiki page: “A9FunctionalTestSetPermission”. 

Edit the wiki page: click “Edit”. 

Restrict viewing of the page by TestUser1: type “ * Set DENYTOPICVIEW = 
%MAINWEB%.TestUser2” (without quote, must have at least six space before *). 
Save the changes. 

Browse to WebHome of Main page. 


. Logout of TestUser1 from TWiki and logout of mdemol! from XTS. 

. Login to XTS as mdemo2 using the TCBE and login to TWiki as TestUser2. 
. Browse to Test_Functional directory using sidebar. 

. Click on wiki page: “A9FunctionalTestSetPermission”. 


OF 


14. Expecting that access to be denied. 

15. Logout of TestUser2 and login as TestUser1, and restore the original permission. 
16. Close the browser window. 

17. Annotate completion by initialing box to the left. 


2.3.10. Changing TWiki Configuration Test Instruction (A10) 


1. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 
the client machine. 

2. In anew browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/configure” as the URL. 

3. Change the following setting: Statistics->{Stats}{TopViews} to 20 (default = 

10)”. 

Click “Next”. 

Type in “password” and click “Save”. 

Expecting a “Updating Configuration: setting 1 configuration item” message. 

Click “return to configuration’. 

Change the setting back to the original value and save the configuration again. 

Close the browser window. 

0. Annotate completion by initialing box to the left. 


SOON DAAK 


2.3.11. Register New User Test Instruction (A11) 


1. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 
the client machine. 
2. In anew browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 
3. Click “Register” on sidebar. 
4. In the Registration page, key in the following: 
m. First Name: Test 
n. Last Name: Userl0 
Email Address: testuser10@mlsserver.cisrlabmlstestbed1.com 
Your Password: password 
Retype password: password 
r. Country: USA 
Click “submit”. 
Expecting successful registration with a “Thank you for registering” message. 
Close the browser window. 
Annotate completion by initialing box to the left. 
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2.4. DAC Tests (Linux) 


2.4.1. TWiki DenyTopicView Permission Test Instruction (BL1) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BLI test page on Test View directory by typing: 
“http://192.168.0.200/twiki/bin/view/Test_DAC_Linux/BL1/TestTopic’” as the 
URL. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 

Repeat steps | to 3, logging in as TestUser2. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 

Repeat steps | to 3, logging in as AdminUser. 


. Expecting access to be granted, displaying content: “Test Text’. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.4.2. TWiki AllowTopicView Permission Test Instruction (BL2) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BL2 test page on Test View directory by typing: 
“http://192.168.0.200/twiki/bin/view/Test_DAC_Linux/BL2/TestTopic’” as the 
URL. 

Expecting access to be granted for TestTopic with content “Test Text’, and with 
the following message on the leftbar: “No permission to view 
Test_DAC_Linux/BL2.WebLeftBar” . 

Close the browser window. 

Repeat steps | to 3, logging in as TestUser2. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 

Repeat steps | to 3, logging in as AdminUser. 

Expecting access to be granted with content: “Test Text’. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.4.3. TWiki AllowWebChange Permission Test Instruction (BL3) 
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. Inanew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Access the BL3 test page on TestChange directory by typing: 
“http://192.168.0.200/twiki/bin/view/Test_DAC_Linux/BL3/TestTopic” as the 
URL. 

Click “Edit’’, insert some text, and click “Save’’. 

Expecting changes be saved successfully. 

Close the browser window. 

Repeat steps | to 4, logging in as TestUser2. 

Expecting change access to be denied, with an error message saying “Access 
Denied”. 

Close the browser window. 


. Repeat steps | to 4, logging in as AdminUser. 

. Insert some text, and click “Save”. 

. Expecting changes be saved successfully. 

. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.4.4. TWiki DenyWebRename Permission Test Instruction (BL4) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BL4 test page on TestChange directory by typing: 
“http://192.168.0.200/twiki/bin/view/Test_DAC_Linux/BL4/TestTopic” as the 
URL. 

Attempt to rename the TestTopic file: click “More topic actions”, then click 
“Rename/move topic... looking for references in all public webs 
(recommended)”. 

Expecting the rename operation to be denied, with an “Access Denied” message. 
Close the browser window. 

Repeat steps | to 4, logging in as TestUser2. 

Expecting the rename operation to be denied, with an error message saying 
“Access Denied”. 

Close the browser window. 


. Repeat steps 1 to 4, logging in as AdminUser. 

. In the “To topic” field, enter ““TestTopicl” as the new topic name. 
. Click “Rename/move’” at the bottom of the page. 

. Expecting the rename operation to be successful. 

. Close the browser window. 

. Annotate completion by initialing box to the left. 
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2.4.5. TWiki View DAC Not Overriding OS DAC Test Instruction (BL5) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BLS test page on Test View directory by typing: 
“http://192.168.0.200/twiki/bin/view/Test_DAC_Linux/BLS5/TestTopic” as the 
URL. 

Expecting access to be granted, but content of TestTopic, 1.e.. “Test text’, is not 
displayed. 

Close the browser window. 

Repeat steps | to 3, logging in as TestUser2. 

Expecting access to be granted, but content of TestTopic, 1.e.. “Test text’, is not 
displayed. 

Close the browser window. 

Repeat steps | to 3, logging in as AdminUser. 


. Expecting access to be granted, but content of TestTopic, 1.e.. “Test text’, is not 


displayed. 


. Close the browser window. 
12. 


Annotate completion by initialing box to the left. 


2.4.6. TWiki Change DAC Not Overriding OS DAC Test Instruction (BL6) 


. Inanew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BL6 test page on TestChange directory by typing: 
“http://192.168.0.200/twiki/bin/view/Test_DAC_Linux/BL6/TestTopic” as the 
URL. 

Click “Edit”, type in some text, and click “Save”. 

Expecting operation to be denied, with an error message saying: “RCS: failed to 
create file path: Permission denied”. 

Close the browser window. 

Repeat steps | to 4, logging in as TestUser2. 

Expecting operation to be denied, with an error message saying: “RCS: failed to 
create file path: Permission denied”. 

Close the browser window. 


. Repeat steps 1 to 4, logging in as AdminUser. 
. Expecting operation to be denied, with an error message saying: “RCS: failed to 


create file path: Permission denied”. 


. Close the browser window. 
. Annotate completion by initialing box to the left. 
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2.4.7. TWiki Rename DAC Not Overriding OS DAC Test Instruction (BL7) 


. In anew browser window connect to TWiki on Linux server. Type: 


“http://192.168.0.200/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BL7 test page on TestRename directory by typing: 
“http://192.168.0.200/twiki/bin/view/Test_DAC_Linux/BL7/TestTopic” as the 
URL. 

Attempt to rename the TestTopic file: click “More topic actions”, then click 
“Rename/move topic... looking for references in all public webs 
(recommended)”. 


. Type “TestTopicl” as the new topic name, and click “Rename/move” at the 


bottom of the page. 

Expecting the rename operation to be denied, with an error message saying 
“During renaming of topic, an error was found. Please notify your TWiki 
administrator’. 

Close the browser window. 

Repeat steps | to 5, logging in as TestUser2. 

Expecting the rename operation to be denied, with an error message saying 
“During renaming of topic, an error was found. Please notify your TWiki 
administrator’. 


. Close the browser window. 
. Repeat steps 1 to 5, logging in as AdminUser. 
. Expecting the rename operation to be denied, with an error message saying 


“During renaming of topic, an error was found. Please notify your TWiki 
administrator’. 


. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.5. DAC Tests (Single Level XTS with NIC configured at sI1:i13) 


2.5.1. TWiki DenyTopicView Permission Test Instruction (BS1) (MAC 
Read Equal) 


. In anew browser window connect to TWiki on Single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BS1 test page on TestView directory by typing: 
“http://192.168.0.220/twiki/bin/view/Test_DAC_SingleLevel/BS1/TestTopic” 
as the URL. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 

Repeat steps | to 3, logging in as TestUser2. 

Expecting access to be denied, with an error message saying “Access Denied”. 
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. Close the browser window. 


Repeat steps | to 3, logging in as AdminUser. 


. Expecting access to be granted, displaying content: “Test Text’. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.5.2. TWiki AllowTopicView Permission Test Instruction (BS2) (MAC 
Read Down) 


In a new browser window connect to TWiki on Single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BS? test page on TestView directory by typing: 
“http://192.168.0.220/twiki/bin/view/Test_DAC_ SingleLevel/BS2/TestTopic” 
as the URL. 

Expecting access to be granted for TestTopic with content “Test Text’, and with 
the following message on the leftbar: “No permission to view 
Test_DAC_SingleLevel/BS2.WebLeftBar” . 

Close the browser window. 

Repeat steps | to 3, logging in as TestUser2. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 

Repeat steps | to 3, logging in as AdminUser. 


. Expecting access to be granted, with content: “Test Text’. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.5.3. TWiki AllowWebChange Permission Test Instruction (BS3) (MAC 
Write Equal) 


. In anew browser window connect to TWiki on Single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Access the BS3 test page on TestChange directory by typing: 
“http://192.168.0.220/twiki/bin/view/Test_DAC_SingleLevel/BS3/TestTopic” 
as the URL. 

Click “Edit”, insert some text, and click “Save”. 

Expecting changes be saved successfully. 

Close the browser window. 

Repeat steps | to 4, logging in as TestUser2. 

Expecting change access to be denied, with an error message saying “Access 
Denied”. 

Close the browser window. 
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Repeat steps | to 4, logging in as AdminUser. 
Insert some text, and click “Save”. 

Expecting changes be saved successfully. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.5.4. TWiki DenyWebRename Permission Test Instruction (BS4) (Write 
Equal) 


. Inanew browser window connect to TWiki on Multilevel XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BS4 test page on TestChange directory by typing: 
“http://192.168.0.220/twiki/bin/view/Test_DAC_SingleLevel/BS4/TestTopic” 
as the URL. 

Attempt to rename the TestTopic file: click “More topic actions”, then click 
“Rename/move topic... looking for references in all public webs 
(recommended)”. 

Expecting the rename operation to be denied, with an “Access Denied” message. 
Close the browser window. 

Repeat steps | to 4, logging in as TestUser2. 

Expecting the rename operation to be denied, with an “Access Denied” message. 
Close the browser window. 


. Repeat steps 1 to 4, logging in as AdminUser. 

. In the “To topic” field, enter ““TestTopic1” as the new topic name. 
. Click “Rename/move’” at the bottom of the page. 

. Expecting the rename operation to be successful. 

. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.5.5. TWiki View DAC Not Overriding OS DAC Test Instruction (BS5) 
(MAC Read Equal) 


. In anew browser window connect to TWiki on Single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BSS test page on TestView directory by typing: 
“http://192.168.0.220/twiki/bin/view/Test_DAC_SingleLevel/BS5/TestTopic” 
as the URL. 

Expecting access to be granted, but content of TestTopic, 1.e.. “Test text’, is not 
displayed. 

Close the browser window. 

Repeat steps | to 3, logging in as TestUser2. 
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7. Expecting access to be granted, but content of TestTopic, i.e.. “Test text’, is not 
displayed. 

8. Close the browser window. 

9. Repeat steps 1 to 3, logging in as AdminUser. 

10. Expecting access to be granted, but content of TestTopic, i.e.. “Test text’, is not 
displayed. 

11. Close the browser window. 

12. Annotate completion by initialing box to the left. 


2.5.6. TWiki Change DAC Not Overriding OS DAC Test Instruction (BS6) 


9. 
10. 
11. 


2 
13; 


2.6. 


2.6. 


(MAC Write Equal) 


In a new browser window connect to TWiki on Single level XTS server. 
Type: “http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Access the BS6 test page on TestChange directory by typing: 
“http://192.168.0.220/twiki/bin/view/Test_DAC_SingleLevel/BS6/TestTop 
ic” as the URL. 

Click “Edit”, type in some text, and click “Save”. 

Expecting operation to be denied, with an error message saying: “RCS: failed 
to create file path: Permission denied”. 

Close the browser window. 

Repeat steps | to 4, logging in as TestUser2. 

Expecting operation to be denied, with an error message saying: “RCS: failed 
to create file path: Permission denied”. 

Close the browser window. 

Repeat steps | to 4, logging in as AdminUser. 

Expecting operation to be denied, with an error message saying: “RCS: failed 
to create file path: Permission denied”. 

Close the browser window. 

Annotate completion by initialing box to the left. 


DAC Tests (Multilevel Level XTS) 


1. TWiki DenyTopicView Permission Test Instruction (BM1) (Read 
Equal) 


1. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 
the client machine. 

2. In anew browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

3. Login to TWiki as TestUser1. 
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Access the BM] test page on Test View directory by typing: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED 
/Test_DAC_MultiLevel/BM1/TestTopic” as the URL. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 

Repeat steps | to 4, logging in as mdemo2 and TestUser2. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 


. Repeat steps 1 to 4, logging in as mdemo2 and AdminUser. 

. Expecting access to be granted, displaying content: “Test Text’. 
. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.6.2. TWiki AllowTopicView Permission Test Instruction (BM2) (Read 
Down) 


. Establish a SIM_SECRET session for mdemol user using the TCBE, for the 


client machine. 

In a new browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BM2 test page on Test View directory by typing: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED 
/Test_DAC_MultiLevel/BM2/TestTopic” as the URL. 

Expecting access to be granted for TestTopic with content “Test Text”, and with 
the following message on the leftbar: “No permission to view 
Test_DAC_SingleLevel/BS2.WebLeftBar’” . 

Close the browser window. 

Repeat steps | to 4, logging in as mdemo2 and TestUser2. 

Expecting access to be denied, with an error message saying “Access Denied”. 
Close the browser window. 


. Repeat steps 1 to 4, logging in as mdemo2 and AdminUser. 
. Expecting access to be granted, with content :““Test Text’. 

. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.6.3. TWiki AllowWebChange Permission Test Instruction (BM3) (MAC 
Write Equal) 


. Establish a SIM_UNCLASSIFIED session for mdemol! user using the TCBE, for 


the client machine. 
In a new browser window connect to TWiki on multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 
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Login to TWiki as TestUser1. 

Access the BM3 test page on TestChange directory by typing: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_DAC_Multi 
Level/BM3/TestTopic” as the URL. 

Click “Edit”, insert some text, and click “Save’’. 

Expecting changes be saved successfully. 

Close the browser window. 

Repeat steps | to 5, logging in as mdemo2 and TestUser2. 

Expecting change access to be denied, with an error message saying “Access 
Denied”. 

Close the browser window. 

Repeat steps | to 5, logging in as mdemo2 and AdminUser. 

Insert some text, and click “Save”. 

Expecting changes be saved successfully. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.6.4. TWiki DenyWebRename Permission Test Instruction (BM4) (Write 
Equal) 


. Establish a SIM_UNCLASSIFIED session for mdemol1 user using the TCBE, for 


the client machine. 


. In anew browser window connect to TWiki on Multilevel XTS server. Type: 


“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BM4 test page on TestChange directory by typing: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED 
/Test_DAC_MultiLevel/BM4/TestTopic” as the URL. 

Attempt to rename the TestTopic file: click “More topic actions”, then click 
“Rename/move topic... looking for references in all public webs 
(recommended)”. 

Expecting the rename operation to be denied, with an “Access Denied” message. 
Close the browser window. 

Repeat steps | to 5, logging in as mdemo2 and TestUser2. 

Expecting the rename operation to be denied, with an “Access Denied” message. 


. Close the browser window. 

. Repeat steps 1 to 5, logging in as mdemo2 and AdminUser. 

. In the “To topic” field, enter ““TestTopicl” as the new topic name. 
. Click “Rename/move’” at the bottom of the page. 

. Expecting the rename operation to be successful. 

. Close the browser window. 

. Annotate completion by initialing box to the left. 
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2.6.5. TWiki View DAC Not Overriding OS DAC Test Instruction (BM5) 
(Read Down) 


. Establish a SIM_SECRET session for mdemol user using the TCBE, for the 


client machine. 

In a new browser window connect to TWiki on Multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Access the BMS test page on Test View directory by typing: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED 
/Test_DAC_MultiLevel/BM5/TestTopic” as the URL. 


. Expecting access to be granted, but content of TestTopic, 1.e.. “Test text”, is not 


displayed. 

Close the browser window. 

Repeat steps | to 4, logging in as mdemo2 and TestUser2. 
Expecting access to be granted, but content of TestTopic, 1.e.. “Test text’, is not 
displayed. 

Close the browser window. 


. Repeat steps 1 to 4, logging in as mdemo2 and AdminUser. 
. Expecting access to be granted, but content of TestTopic, i.e.. “Test text’, is not 


displayed. 


. Close the browser window. 
13. 


Annotate completion by initialing box to the left. 


2.6.6. TWiki Rename DAC Not Overriding OS DAC Test Instruction (BM6) 
(Write equal) 


. Establish a SIM_UNCLASSIFIED session for mdemol] user using the TCBE, for 
the client machine. 

. In anew browser window connect to TWiki on Multilevel XTS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

. Login to TWiki as TestUser1. 

. Access the BM6 test page on TestRename directory by typing: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED 

/Test_ DAC_MultiLevel/BM6/TestTopic” as the URL. 

. Attempt to rename the TestTopic file: click “More topic actions”, then click 
“Rename/move topic... looking for references in all public webs 
(recommended)”. 

. Type “TestTopicl” as the new topic name, and click “Rename/move’” at the 
bottom of the page. 

. Expecting the rename operation to be denied, with an error message saying 
“During renaming of topic, an error was found. Please notify your TWiki 
administrator’. 


. Close the browser window. 
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Repeat steps | to 6, logging in as mdemo2 and TestUser2. 


. Expecting the rename operation to be denied, with an error message saying 


“During renaming of topic, an error was found. Please notify your TWiki 
administrator’. 


. Close the browser window. 
. Repeat steps 1 to 6, logging in as mdemo2 and AdminUser. 
. Expecting the rename operation to be denied, with an error message saying 


“During renaming of topic, an error was found. Please notify your TWiki 
administrator’. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.7. MAC Test (Single Level XTS with NIC configured at sI1:i13) 


2.7.1. Display Unauthorized Wiki Pages (MAC read up & DAC allowed) 
Test Instruction (CS1) 


. In anew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

View a s12:i13 page. Type: 
“http://192.168.0.220/twiki/bin/view/Test_ MAC _ SingleLevel/CS1/TestTopic” 
as the URL. 

Expecting an error message saying “The Test_MAC_SingleLevel/CS1 web does 
not exist’. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.7.2. Display Authorized Wiki Pages (MAC read down & DAC allowed) 
Test Instruction (CS2) 


. Inanew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

View a sl0:i13 page. Type: 
“http://192.168.0.220/twiki/bin/view/Test_ MAC _ SingleLevel/CS2/TestTopic” 
as the URL. 

Expecting a display of the wiki page, with content: “Test Text’. 

Close the browser window. 

Annotate completion by initialing box to the left. 
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2.7.3. Display Authorized Wiki Pages (MAC read equal & DAC allowed) 
Test Instruction (CS3) 


. Inanew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

View a sl1:il13 page. Type: 
“http://192.168.0.220/twiki/bin/view/Test_ MAC _SingleLevel/CS3/TestTopic” 
as the URL. 

Expecting a display of the wiki page, with content: “Test Text’. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.7.4. Edit Unauthorized File (MAC write up & DAC allowed) Test 
Instruction (CS4) 


. Inanew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Attempt to edit a s12:113 page. Type: 
“http://192.168.0.220/twiki/bin/view/Test_ MAC _SingleLevel/CS4/TestTopic” 
as the URL. 

Expecting an error message saying “The Test_MAC_SingleLevel/CS4 web does 
not exist’. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.7.5. Edit Unauthorized File (MAC write down & DAC allowed) Test 
Instruction (CS5) 


In a new browser window connect to TWiki on single level XTS server. Type: 
“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Attempt to edit a sl0:113 page. Type: 
“http://192.168.0.220/twiki/bin/view/Test_ MAC _ SingleLevel/CS5/TestTopic” 
as the URL, then click “Edit”. 

Expecting error message saying “RCS: failed to create file path: permission 
denied”. 

Close the browser window. 

Annotate completion by initialing box to the left. 
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2.7.6. Edit Authorized Wiki Page (MAC write equal & DAC allowed) Test 
Instruction (CS6) 


. Inanew browser window connect to TWiki on single level XTS server. Type: 


“http://192.168.0.220/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Attempt to edit a sl1:113 page. Type: 
“http://192.168.0.220/twiki/bin/view/Test_ MAC _SingleLevel/CS6/TestTopic” 
as the URL, then click “Edit”. 

Modify the wiki page and save the modified wiki page. 

Expecting successful modification and display of the modified content. 

Modify the wiki page to its original state and save. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.8. MAC Test (Multilevel XTS) 


2.8.1. Display Unauthorized Wiki Pages (MAC read up & DAC allowed) 
Test Instruction (CM1) 


. Establish a SIM_UNCLASSIFIED session for mdemol1 user using TCBE, for the 


client machine. 

In a new browser window connect to TWiki on MLS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

View a SIM_SECRET page. Type: 
“http://192.168.0.130/twiki/bin/view/SIM_SECRET/Test_MAC MultiLevel/ 
CM1/TestTopic” as the URL. 

Expecting an error message saying “The 
SIM_SECRET/Test_MAC_MultiLevel/CM1 web does not exist’. 
Close the browser window. 

Annotate completion by initialing box to the left. 


2.8.2. Display Authorized Wiki Pages (MAC read down & DAC allowed) 
Test Instruction (CM2) 


. Establish a SIM_SECRET session for mdemol1 user using TCBE, for the client 


machine. 

In a new browser window connect to TWiki on MLS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

View a SIM_UNCLASSIFIED page. Type: 
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“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_MAC_Mult 
iLevel/CM2/TestTopic” as the URL. 

Expecting a display of the wiki page, with content: “Test Text’. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.8.3. Display Authorized Wiki Pages (MAC read equal & DAC allowed) 
Test Instruction (CM3) 


. Establish a SIM_UNCLASSIFIED session for mdemol1 user using TCBE, for the 


client machine. 

In a new browser window connect to TWiki on MLS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

View a SIM_UNCLASSIFIED page. Type: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_MAC_Mult 
iLevel/CM3/TestTopic” as the URL. 

Expecting a display of the wiki page, with content: “Test Text”. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.8.4. Edit Unauthorized File (MAC write up & DAC allowed) Test 
Instruction (CM4) 


. Establish a SIM_UNCLASSIFIED session for mdemol! user using the TCBE, for 


the client machine. 


. In anew browser window connect to TWiki on MLS server. Type: 


“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Attempt to edit a SIM_SECRET page. Type: 
“http://192.168.0.130/twiki/bin/view/SIM_SECRET/Test_MAC MultiLevel/ 
CM4/TestTopic” as the URL. 

Expecting an error message saying “The 
SIM_SECRET/Test_MAC_MultiLevel/CM4 web does not exist’. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.8.5. Edit Unauthorized File (MAC write down & DAC allowed) Test 
Instruction (CM5) 


. Establish a SIM_SECRET session for mdemol user using the TCBE, for the 


client machine. 
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. Inanew browser window connect to TWiki on MLS server. Type: 


“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Attempt to edit a SIM_UNCLASSIFIED page. Type: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_MAC_Mult 
iLevel/CMS5/TestTopic” as the URL. 

Click “Edit”. 

Expecting error message saying: “RCS: failed to create file path: Permission 
denied”. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.8.6. Edit Authorized Wiki Page (MAC write equal & DAC allowed) Test 
Instruction (CM6) 


. Establish a SIM_UNCLASSIFIED session for mdemol! user using the TCBE, for 


the client machine. 

In a new browser window connect to TWiki on MLS server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Attempt to edit a SIM_UNCLASSIFIED page. Type: 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_MAC_Mult 
iLevel/CM6/TestTopic” as the URL. 

Click “Edit”, type some text, and click “Save”. 

Expecting successful modification and display of the modified content. 
Modify the wiki page to its original state and save. 

Close the browser window. 

Annotate completion by initialing box to the left. 


2.8.7.. Link Unauthorized Wiki Page (MAC write equal, read up & DAC 
allowed) Test Instruction (CM7) 


. Establish a SIM_UNCLASSIFIED session for mdemol! user using the TCBE, for 


the client machine. 


. In anew browser window connect to TWiki on MLS server. Type: 


“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Attempt to edit a SIM_UNCLASSIFIED page. Type: 

“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_MAC_Mult 

iLevel/CM7/TestTopic” as the URL. 

Click “Edit”, type the following (without quote): 
“TLSIM_SECRET.CM4.TestTopic][secretlink]]”, and click “Save”. 

Expecting successful modification and display of the modified content. 
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Click on the “secretlink?’’ link. 

Expecting a message saying “The SIM_SECRET/CM4 web does not exist’. 
Click “Create a new web” at the bottom of the page. 

In the “Adding a New Web” page, click “create new web”. 


. Expecting an error message saying Access Denied. 
. Repeat steps | to 9, logging in as mdemo2 and AdminUser. 
. Expecting an error message saying “RCS: failed to create file path: Permission 


denied’. 


. Modify the wiki page to its original state and save. 
. Close the browser window. 
. Annotate completion by initialing box to the left. 


2.9. Integration Tests 


2.9.1. Switch to Wiki Test Instruction (D1) 


. Establish a SIM UNCLASSIFIED session for mdemol user to MYSEA MLS 


server using the TCBE, for the client machine. 

In a new explorer window connect to WebDAV on the MYSEA MLS server. 
Type: “\\192.168.0.131\dav” as the URL. 

Verify that it is working by editing any file. 

Logout from the MYSEA MLS server. Type: “logout” at the TCBE. 

Close the explorer window. 

Establish a SIM_UNCLASSIFIED session for mdemol user to wiki server using 
the TCBE, for the Client machine. 

In a new browser window connect to TWiki on the server. Type: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 

Login to TWiki as TestUser1. 

Verify that it is working by accessing a SIM_UNCLASSIFIED directory by 
typing 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_Integration 
/TestTopic” as the URL. 


. Click “Edit”. 

. Type in some text, and click “Save”. 

. Expecting successful modification and display of the modified content. 
. Close the browser window. 

. Annotate completion by initialing box to the left. 


2.9.2. Switch to WebDAV Test Instruction (D2) 


. Establish a SIM_UNCLASSIFIED session for mdemol1 user to wiki server using 


the TCBE, for the client machine. 
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. In anew browser window connect to TWiki on the server. Type: 


“http://192.168.0.130/twiki/bin/view/Main/WebHome” as the URL. 
Login to TWiki as TestUser1. 

Verify that it is working by accessing a SIM_UNCLASSIFIED directory by 
typing 
“http://192.168.0.130/twiki/bin/view/SIM_UNCLASSIFIED/Test_Integration 
/TestTopic” as the URL. 

Click “Edit”. 

Type in some text, and click “Save”. 

Expecting successful modification and display of the modified content. 
Close the browser window. 

Logout from the wiki server. Type: “logout” at the TCBE. 


. Establish a SIM_ UNCLASSIFIED session for mdemol user to MYSEA MLS 


server using the TCBE, for the Client machine. 


. In anew explorer window connect to WebDAV on the MYSEA MLS server. 


Type: “\\192.168.0.131\dav” as the URL. 


. Verify that it is working by editing any file. 
. Close the explorer window. 
. Annotate completion by initialing box to the left. 
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APPENDIX C: MLS TWIKI USER GUIDE 


This appendix provides a simple user guide for the MLS TWiki running on the 
MYSEA server. Detailed documentation of standard TWiki can be found in the TWiki 


website at “http://twiki.org/cgi-bin/view/T Wiki04x01/TWikiReferenceManual”. 


A. MLS TWIKI WEB ORGANIZATION 


There are three webs in the default MLS TWiki installation, namely the Main 
web, the TWiki web, and the Sandbox web. The Main web is the home page. It is also 
the web where all users’ homepages are created when users register for TWiki account. 
The TWiki web is the web where the online documentations and other administration 
pages, e.g., user registration and password change, are stored. The Sandbox web is the 
place where users can create temporary topics for testing. These three webs are created at 
the SIM_UNCLASSIFIED level, i.e., to edit the web, users must be logged in at the 
SIM_UNCLASSIFIED level. 


Besides the three default webs, the MLS TWiki has seven more webs, each 
created at a different security levels. Users will create contents in the appropriate web 
that corresponds to the security labels of the contents. The seven webs and their 
corresponding levels are: 

e SIM_UNCLASSIFED web, s11:i10 

e SIM_CONFIDENTIAL web, s13:i10 

e SIM_SECRET web, sl5(sc1):i10 

e SIM_PACIFIC_SECRET web, sl5(sc2): 110 

e SIM_NATO_SECRET web, sl5(sc3):i10 

e COALITION_COMMAND web, sl5(sc1 sc2 sc3): i10 
e SIM_TOP_SECRET web, s17:il0 
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B. GETTING STARTED 


1. Log in the MLS wiki server through the TPE or TCBE software. Set session 
level to SIM_UNCLASSIFIED. 


2. At the SIM_UNCLASSIFIED level, users will be able to register for new 
TWiki accounts, change password for existing TWiki accounts, and create test pages in 
Sandbox. Users are also able to read and edit contents within the Main, TWiki, and 
SIM_UNCLASSIFIED web in accordance to the permitted TWiki DAC settings of the 


respective contents. Users will not be able to read or edit contents from other webs. 


3. To read or edit contents at other security level, set the session level to be equal 
to that security level. For example, to read or edit a page at SIM SECRET, set the 
session level to SIM_SECRET using the TPE or TCBE software. Users will be able to 
read down, i.e. at SIM SECRET, users will be able to read contents in the 
SIM_SECRET, SIM CONFIDENTIAL and SIM_UNCLASSIFIED webs, as well as the 
default webs of Main, TWiki and Sandbox, in accordance to the TWiki DAC settings. 
However, the users are not able to read contents at security levels higher than 
SIM_SECRET. Users can only write at the level equal to their session level, i.e. the users 
can only edit contents in SIM_SECRET web, and only if TWiki DAC settings permit. At 
security levels other than SIM_UNCLASSIFIED, users are not able to register for new 


TWiki accounts or change password for existing TWiki accounts. 


C, BASIC OPERATIONS 


1. Registering for new account 


e Login to TPE or TCBE using STOP user ID and password, at SIM_UNCLASSIFIED 
level. 


e Open a _ browser, and type the following as the URL: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome”. 


e For first time users, click the “register” link. Fill in the following mandatory fields 
with the appropriate values, and click “Submit”: 


e First Name: 
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® Last Name: 
e Email Address: 


e Your Password: 
e Retype password: 
e Country: 


The user will be prompted with a “Thank you for registering” message, and will be 
able to start using the TWiki system. 


2. Editing a topic: 


Login to TPE or TCBE using STOP user ID and password, and select the appropriate 
session level, e.g., SIM_SECRET. 


Open a _ browser, and type the following as the URL: 
“http://192.168.0.130/twiki/bin/view/Main/WebHome”’. 


Login to TWiki using TWiki user ID and password. 
Browse to the appropriate web, e.g., SIM_SECRET web. 
Click “Edit” at the bottom of the topic. 

Enter the changes. 


Click “Save” to save the changes. 


3. Creating a topic 


In an existing page, create a link to the new page by typing [[newpage]], substituting 
newpage with the appropriate name. 


Save the changes by clicking “Save”. User will then be presented with the content of 
the newly modified page. 


Click on the “?” beside the newpage text. User will be presented with the text edit 
form. Type in the content and click “Save”. The newpage topic will be created. 


4. Deleting a topic 
Click on “More topic actions” on the lower right corner of the topic to be deleted. 


Click “Delete topic..., looking for references in all public webs (recommended)” 
option. 


Click ‘“‘Delete’’ in the next screen. 


The topic will be deleted. 
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55 Edit/create a topic at other levels: 


Go to TPE or TCBE, type s/ and type the security level to change to, e.g., to change 
to SIM_TOP_SECRET, type “SIM_TOP_SECRET”. 


Browser to the appropriate webs or topics and follow the procedure for editing, 
creating or deleting pages as outlined above. 
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